idnits 2.17.1 draft-simpson-photuris-secret-00.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-16) 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. == 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 80: '..., the same value MAY be used by multip...' RFC 2119 keyword, line 172: '...ation Exchange. The value MUST NOT be...' RFC 2119 keyword, line 267: '...ation Exchange. The value MUST NOT be...' RFC 2119 keyword, line 268: '... Also, the value MUST NOT equal the PS...' RFC 2119 keyword, line 414: '... secret-keys MUST be discarded....' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (May 1998) is 9468 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 == Missing Reference: 'RFC-2119' is mentioned on line 64, but not defined == Missing Reference: 'RFC-2065' is mentioned on line 519, but not defined ** Obsolete undefined reference: RFC 2065 (Obsoleted by RFC 2535) == Missing Reference: 'RFC-1991' is mentioned on line 569, but not defined ** Obsolete undefined reference: RFC 1991 (Obsoleted by RFC 4880) ** Downref: Normative reference to an Experimental draft: draft-simpson-photuris (ref. 'RFC-zzzz') Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W A Simpson [DayDreamer] 3 Internet Draft 4 expires in six months May 1998 6 Photuris: Secret Exchange 7 draft-simpson-photuris-secret-00.txt 9 Status of this Memo 11 This document is an Internet-Draft. Internet Drafts are working doc- 12 uments of the Internet Engineering Task Force (IETF), its Areas, and 13 its Working Groups. Note that other groups may also distribute work- 14 ing documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months, and may be updated, replaced, or obsoleted by other documents 18 at any time. It is not appropriate to use Internet Drafts as refer- 19 ence material, or to cite them other than as a ``working draft'' or 20 ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 24 Directories on: 26 ftp.is.co.za (Africa) 27 nic.nordu.net (Northern Europe) 28 ftp.nis.garr.it (Southern Europe) 29 ftp.ietf.org (Eastern USA) 30 ftp.isi.edu (Western USA) 31 munnari.oz.au (Pacific Rim) 33 Distribution of this memo is unlimited. 35 Copyright Notice 37 Copyright (C) William Allen Simpson (1995,1998). All Rights 38 Reserved. 40 Abstract 42 Photuris is a session-key management protocol. Extensible Messages 43 are provided to enable future implementation changes without affect- 44 ing the basic protocol. 46 The Secret Exchange messages provide the capability to create 47 ephemeral symmetric secrets between parties. 49 1. Introduction 51 In addition to establishing session-keys, Photuris is easily capable 52 of generating high quality unpredictable secrets. This facility can 53 be useful to augment or expand lower quality user passwords, and to 54 substitute for computationally expensive public-key operations. 56 The packet format and basic facilities are already defined for Pho- 57 turis [RFC-zzzz]. 59 1.1. Terminology 61 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 62 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 63 described in [RFC-2119]. 65 nonce A value that is not used more than once for the same 66 purpose. The value is recommended to be generated 67 by a cryptographically random method, which may be 68 concatenated with a timestamp or sequence number. 70 Party Secret Index (PSI) 71 A number that indicates a particular symmetric 72 secret. The number is unique relative to the IP 73 Destination, which is the PSI Owner. The value is 74 recommended to be generated by a cryptographically 75 random method. 77 The use of this value is orthogonal to usage of sim- 78 ilar values by other related security protocols, 79 such as the Security-Parameters-Index (SPI). That 80 is, the same value MAY be used by multiple protocols 81 to concurrently indicate different Security Associa- 82 tion parameters. 84 2. Secret Exchange 86 The Secret Exchange will occur following the usual Value Exchange: 88 Initiator Responder 89 ========= ========= 90 Cookie_Request -> 91 <- Cookie_Response 92 Value_Request -> 93 <- Value_Response 95 [generate shared-secret from exchanged values] 97 Frequently, the Secret Exchange will occur before the Identification 98 Exchange: 100 Initiator Responder 101 ========= ========= 102 Secret_Request -> 103 <- Secret_Response 105 [make PSI secret-keys in each direction] 107 Identity_Request -> 108 <- Identity_Response 110 [make SPI session-keys in each direction] 112 Alternatively, the Secret Exchange can occur in the middle of the 113 Identification Exchange: 115 Initiator Responder 116 ========= ========= 117 Identity_Request -> 118 <- Secret_Request 119 Secret_Response -> 121 [make PSI secret-keys in each direction] 123 <- Identity_Response 125 [make SPI session-keys in each direction] 127 Finally, the Secret Exchange can occur at both times. 129 The exchange of messages is ordered, although the formats and mean- 130 ings of the messages are identical in each direction. The messages 131 are easily distinguished by the parties themselves, by examining the 132 Message and Identification fields. 134 2.1. Secret_Request 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | | 138 ~ Initiator-Cookie ~ 139 | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | | 142 ~ Responder-Cookie ~ 143 | | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Message | LifeTime | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Party-Secret-Index | 148 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 149 | Identity-Choice | | 150 + + + + + + + + + + + + + + + + + + 151 | | 152 ~ Identification ~ 153 | | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 ... Padding | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 Initiator-Cookie 16 bytes. Copied from the Value_Request. 160 Responder-Cookie 16 bytes. Copied from the Value_Request. 162 Message 6 164 LifeTime 3 bytes. The number of seconds remaining before the 165 indicated PSI expires. 167 When zero, indicates that the PSI is used for only 168 this Identification Exchange. 170 Party-Secret-Index (PSI) 171 4 bytes. The PSI to be used for this party in the 172 Identification Exchange. The value MUST NOT be 173 zero. 175 Identity-Choice 2 or more bytes. An identity attribute is selected 176 from the list of Offered-Attributes sent by the 177 peer. 179 The field may be any integral number of bytes in 180 length, as indicated by its Length field. It does 181 not require any particular alignment. The 16-bit 182 alignment shown is for convenience in the illustra- 183 tion. 185 Identification Variable Precision Integer, or alternative format 186 indicated by the Identity-Choice. See the "Addi- 187 tional Attributes" for details. 189 The field may be any integral number of bytes in 190 length. It does not require any particular align- 191 ment. The 32-bit alignment shown is for convenience 192 in the illustration. 194 Padding 8 to 255 bytes. This field is filled up to at least 195 a 128 byte boundary, measured from the beginning of 196 the message. The number of pad bytes are chosen 197 randomly. 199 In addition, when a Privacy-Method indicated by the 200 current Scheme-Choice requires the plaintext to be a 201 multiple of some number of bytes (the block size of 202 a block cipher), this field is adjusted as necessary 203 to the size required by the algorithm. 205 Self-Describing-Padding begins with the value 1. 206 Each byte contains the index of that byte. Thus, 207 the final pad byte indicates the number of pad bytes 208 to remove. For example, when the unpadded message 209 length is 120 bytes, the padding values might be 1, 210 2, 3, 4, 5, 6, 7, and 8. 212 The portion of the message after the PSI field is masked using the 213 Privacy-Method indicated by the current Scheme-Choice. 215 The fields following the PSI are opaque. That is, the values are set 216 prior to masking (and optional encryption), and examined only after 217 unmasking (and optional decryption). 219 2.2. Secret_Response 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | | 223 ~ Initiator-Cookie ~ 224 | | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | | 227 ~ Responder-Cookie ~ 228 | | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Message | LifeTime | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Party-Secret-Index | 233 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 234 | Identity-Choice | | 235 + + + + + + + + + + + + + + + + + + 236 | | 237 ~ Secret-Value ~ 238 | | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | | 241 ~ Verification ~ 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | (Identity-Choice) | | 245 + + + + + + + + + + + + + + + + + + 246 | | 247 ~ (Identification) ~ 248 | | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 ... Padding | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Initiator-Cookie 16 bytes. Copied from the Secret_Request. 255 Responder-Cookie 16 bytes. Copied from the Secret_Request. 257 Message 5 259 LifeTime 3 bytes. The number of seconds remaining before the 260 indicated PSI expires. 262 When zero, indicates that the PSI is used for only 263 this Identification Exchange. 265 Party-Secret-Index (PSI) 266 4 bytes. The PSI to be used for this party in the 267 Identification Exchange. The value MUST NOT be 268 zero. Also, the value MUST NOT equal the PSI from 269 the Secret_Request. 271 Identity-Choice 2 or more bytes. A symmetric identity attribute is 272 selected from the list of Offered-Attributes sent by 273 the peer, and is used to calculate the Verification. 275 The field may be any integral number of bytes in 276 length, as indicated by its Length field. It does 277 not require any particular alignment. The 16-bit 278 alignment shown is for convenience in the illustra- 279 tion. 281 Secret-Value Variable Precision Integer, or alternative format 282 indicated by the Secret_Request Identity-Choice. 283 Used for calculating a pair of symmetric secret-keys 284 between the parties. 286 The field may be any integral number of bytes in 287 length, as indicated by its Size field. It does not 288 require any particular alignment. The 32-bit align- 289 ment shown is for convenience in the illustration. 291 Verification Variable Precision Integer, or alternative format 292 indicated by the Identity-Choice. The calculation 293 of the value is described in "Secret Verification". 295 The field may be any integral number of bytes in 296 length. It does not require any particular align- 297 ment. The 32-bit alignment shown is for convenience 298 in the illustration. 300 (Identity-Choice) 301 2 or more bytes. An identity attribute is selected 302 from the list of Offered-Attributes sent by the 303 peer. 305 This field is optional. Its presence is indicated 306 by the UDP Length after removing the Padding (UDP 307 Length - last Padding value). 309 The field may be any integral number of bytes in 310 length, as indicated by its Length field. It does 311 not require any particular alignment. The 16-bit 312 alignment shown is for convenience in the 313 illustration. 315 (Identification) Variable Precision Integer, or alternative format 316 indicated by the Identity-Choice. See the "Addi- 317 tional Attributes" for details. 319 This field is optional. Its presence is indicated 320 by the UDP Length after removing the Padding (UDP 321 Length - last Padding value). 323 The field may be any integral number of bytes in 324 length. It does not require any particular align- 325 ment. The 32-bit alignment shown is for convenience 326 in the illustration. 328 Padding 8 to 255 bytes. This field is filled up to at least 329 a 128 byte boundary, measured from the beginning of 330 the message. The number of pad bytes are chosen 331 randomly. 333 In addition, when a Privacy-Method indicated by the 334 current Scheme-Choice requires the plaintext to be a 335 multiple of some number of bytes (the block size of 336 a block cipher), this field is adjusted as necessary 337 to the size required by the algorithm. 339 Self-Describing-Padding begins with the value 1. 340 Each byte contains the index of that byte. Thus, 341 the final pad byte indicates the number of pad bytes 342 to remove. For example, when the unpadded message 343 length is 120 bytes, the padding values might be 1, 344 2, 3, 4, 5, 6, 7, and 8. 346 The portion of the message after the PSI field is masked using the 347 Privacy-Method indicated by the current Scheme-Choice. 349 The fields following the PSI are opaque. That is, the values are set 350 prior to masking (and optional encryption), and examined only after 351 unmasking (and optional decryption). 353 2.3. Secret-Nonce 355 A secret-nonce is derived as indicated by the Identity-Choice speci- 356 fied in the Secret_Request. 358 Asymmetric Identity Attributes 359 The Secret-Value contains the secret-nonce encoded by the public- 360 key. 362 Symmetric Identity Attributes 363 The Value part of the Secret-Value is concatenated to (followed 364 by) the existing symmetric secret-key. 366 Regardless of the internal representation of the secret-nonce, when 367 used in calculations it is in the same form as the Value part of a 368 Variable Precision Integer: 370 - most significant byte first. 371 - bits used are right justified within byte boundaries. 372 - any unused bits are in the most significant byte. 373 - unused bits are zero filled. 375 The secret-nonce does not include a Size field. 377 2.4. Secret-Key Computation 379 Each pair of PSI values is used to generate a corresponding pair of 380 symmetric secret-keys (one for each party). 382 The Scheme-Choice specified Key-Generation-Function is calculated 383 over the following concatenated values: 385 + the Initiator Cookie, 386 + the Responder Cookie, 387 + the Owner Message, LifeTime and PSI, 388 + the secret-nonce, 389 + the Peer Message, LifeTime and PSI, 390 + the computed shared-secret. 392 Since the order of the Owner and Peer fields is different in each 393 direction, the resulting secret-key will usually be different in each 394 direction. 396 Following verification, the pair of PSI values also identifies the 397 secret-keys. The primary (Requester) identity is the Secret_Request 398 PSI value concatenated to (followed by) the Verification value. The 399 secondary (Peer) identity is the Secret_Request PSI value, concate- 400 nated to (followed by) the Secret_Response PSI value, concatenated to 401 (followed by) the Verification value. These identities can be used 402 with a Symmetric Identity Attribute in any subsequent Identification 403 message. The Secret_Request LifeTime is used as the LifeTime for 404 both secret-keys. 406 Implementation Notes: 408 The exact details of the secret-nonce and Secret-Value field that 409 are included in the secret-key calculation are dependent on the 410 Secret_Request Identity-Choice and Identification. 412 The Secret Exchange ultimately depends upon the Identification 413 Exchange for verification. When verification fails, the PSI 414 secret-keys MUST be discarded. 416 2.5. Secret Verification 418 The Secret_Response is authenticated using the Identity-Choice. The 419 Verification value is calculated prior to masking (and optional 420 encryption), and verified after unmasking (and optional decryption). 422 The Identity-Choice authentication function is supplied with two 423 input values: 425 - the secondary PSI secret-key, 426 - the data to be verified (as a concatenated sequence of bytes). 428 The resulting output value is stored in the Verification field. 430 The Identity-Choice verification data consists of the following con- 431 catenated values: 433 + the Initiator Cookie, 434 + the Responder Cookie, 435 + the Secret_Request Message, LifeTime and PSI fields, 436 + the Secret_Request Identity-Choice and Identification, 437 + the Secret_Response Message, LifeTime and PSI fields, 438 + the Secret_Response Identity-Choice and Secret-Value, 439 + the Secret_Response Identity-Choice and Identification (optional), 440 + the Padding. 442 Note that the order of the Message, LifeTime and PSI fields are dif- 443 ferent in each direction. 445 If the verification fails, the users are notified, and a Verifica- 446 tion_Failure message is sent, without adding any PSIs. On success, 447 normal operation begins with the remainder of the Identification 448 Exchange. 450 Implementation Notes: 452 The exact details of the Identifications and secret-nonce included 453 in the Verification calculation are dependent on the corresponding 454 Identity-Choices. 456 Failure to find an Identification in either an internal or exter- 457 nal database results in the same Verification_Failure message as 458 failure of the verification computation. 460 The Secret-Value data includes both the Size and Value fields. 462 2.6. Optional Identification 464 When the optional Identity-Choice and Identification fields are 465 included in the Secret_Response, the next Identification message is 466 modified. The Identity-Choice and Identification fields are replaced 467 by Identity-Choice and Secret-Value fields in the same manner as the 468 Secret_Response format. 470 The SPI value is used as a PSI value to generate two additional PSI 471 secret-keys, yielding a total of four PSI secret-keys. The secondary 472 PSI secret-key is used to calculate the sender (SPI Owner) verifica- 473 tion-key, and is used directly as the generation-key. 475 Following verification, the pair of PSI and SPI values also identi- 476 fies the secret-keys. The primary (Responder) identity is the 477 Secret_Response PSI value concatenated to (followed by) the Verifica- 478 tion value. The secondary (Peer) identity is the Secret_Response PSI 479 value, concatenated to (followed by) the SPI value, concatenated to 480 (followed by) the Verification value. These identities can be used 481 with a Symmetric Identity Attribute in any subsequent Identification 482 message. The Secret_Response LifeTime is used as the LifeTime for 483 both additional secret-keys. 485 Implementation Notes: 487 The exact details of the secret-nonce and Secret-Value field that 488 are included in the secret-key calculation are dependent on the 489 Secret_Response optional Identity-Choice and Identification. 491 The Secret-Value data includes both the Size and Value fields. 493 3. Additional Attributes 495 The attribute format and basic facilities are already defined for 496 Photuris [RFC-zzzz]. 498 These optional attributes are specified separately, and no single 499 implementation is expected to support all of them. 501 This document defines the following values: 503 Use Type 504 I 27 DNS-Key 505 I 28 PGP 507 I Identity-Choice 509 3.1. DNS-Key 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Type | Length | Algorithm | Power | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 Type 27 517 Length 2 519 Algorithm An algorithm supported. See [RFC-2065] for details. 520 Examples include: 522 1 RSA with MD5 (support optional). 523 3 DSA with SHA1 (support required). 525 Power The maximum public/private-key bits supported, 526 expressed as a power of two. As a minimum, it is 527 required that all implementations of this attribute 528 support value 10 (1024-bit keys). 530 When more than one version is supported, multiple attributes are 531 listed in the Offered-Attributes. 533 Asymmetric Identification 535 When selected as an Identity-Choice, the immediately following 536 Identification field consists of the binary form of the DNS-Key 537 Resource Record. The domain name is fully expanded (no name 538 compression via pointers). 540 No DNS-Signature Resource Records are included with the Identifi- 541 cation. Valid Identifications and corresponding signature cer- 542 tificates are preconfigured by the parties, or maintained in 543 external databases. 545 The Identification is not contained within a Variable Precision 546 Integer (VPI). The Key RR elements are parsed by the implementa- 547 tion to determine the end of the Identification field. 549 This attribute is never used for [RFC-zzzz] "Identity Verifica- 550 tion" or "Validity Verification". Instead, a Secret Exchange 551 occurs to associate a pair of symmetric secrets with the Identifi- 552 cation. 554 The Secret-Value consists of a public-key encrypted secret-nonce 555 of the form determined by the DNS-Key algorithm. The size of the 556 secret-nonce is determined by the size of the public-key. The 557 result is contained within a Variable Precision Integer (VPI). 559 3.2. PGP Identification 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Type | Length | Version | Power | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Type 28 567 Length 2 569 Algorithm An algorithm supported. See [RFC-1991] for details. 570 Examples include: 572 3 PGP 2.6.x 573 RSA with MD5 (support optional). 574 4 PGP 5.0.x 575 DSA with SHA1 (support required). 577 Power The maximum public/private-key bits supported, 578 expressed as a power of two. As a minimum, it is 579 required that all implementations of this attribute 580 support value 10 (1024-bit keys). 582 When more than one version is supported, multiple attributes are 583 listed in the Offered-Attributes. 585 Asymmetric Identification 587 When selected as an Identity-Choice, the immediately following 588 Identification field consists of a PGP public-key element, fol- 589 lowed by one or more PGP user identity elements. 591 No PGP Signature elements are included in the Identification. 592 Valid Identifications and corresponding signature certificates are 593 preconfigured by the parties, or maintained in external databases. 595 The Identification is not contained within a Variable Precision 596 Integer (VPI). The PGP elements are parsed by the implementation 597 to determine the end of the Identification field. 599 This attribute is never used for [RFC-zzzz] "Identity Verifica- 600 tion" or "Validity Verification". Instead, a Secret Exchange 601 occurs to associate a pair of symmetric secrets with the Identifi- 602 cation. 604 The Secret-Value consists of a public-key encrypted secret-nonce 605 in the form of a PGP Public-Key-Encrypted element. The size of 606 the secret-nonce is determined by the size of the public-key. 608 The Secret-Value is not contained within a Variable Precision 609 Integer (VPI). The PGP elements are parsed by the implementation 610 to determine the end of the Secret-Value field. 612 Nota Bene: 614 The PGP Multi-Precision Integer (MPI) is very similar to the 615 Variable Precision Integer (VPI). However, the Size field is 616 not extensible, and PGP library functions truncate leading sig- 617 nificant zeroes. 619 Security Considerations 621 Acknowledgements 623 William Simpson was responsible for the packet formats, additional 624 message types, editing and formatting. All such mistakes are his 625 responsibity. 627 Hilarie Orman suggested adding secret "nonces" to session-key genera- 628 tion for asymmetric public/private-key identity methods. 630 References 632 [RFC-zzzz] Karn, P., and Simpson, W., "Photuris: Session Key Manage- 633 ment Protocol", draft-simpson-photuris-18.txt, work in 634 progress. 636 Contacts 638 Comments about this document should be discussed on the pho- 639 turis@adk.gr mailing list. 641 Questions about this document can also be directed to: 643 William Allen Simpson 644 DayDreamer 645 Computer Systems Consulting Services 646 1384 Fontaine 647 Madison Heights, Michigan 48071 649 wsimpson@UMich.edu 650 wsimpson@GreenDragon.com (preferred) 652 Full Copyright Statement 654 Copyright (C) William Allen Simpson (1995,1998). All Rights 655 Reserved. 657 This document and translations of it may be copied and furnished to 658 others, and derivative works that comment on or otherwise explain it 659 or assist in its implementation may be prepared, copied, published 660 and distributed, in whole or in part, without restriction of any 661 kind, provided that the above copyright notice and this paragraph are 662 included on all such copies and derivative works. However, this doc- 663 ument itself may not be modified in any way, except as required to 664 translate it into languages other than English. 666 This document and the information contained herein is provided on an 667 "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR 668 IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF 669 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 670 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.