Network Working Group W A Simpson Internet Draft [DayDreamer] expires in six months March 1999 Photuris: Secret Exchange draft-simpson-photuris-secret-01.txt (B) Status of this Memo This document is an Internet Draft, and is in full conformance with all provisions of Section 10 of RFC2026, except that the right to produce derivative works is not granted. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as "Work In Progress." The list of current Internet Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. To view the list of Internet Draft Shadow Directories, see http://www.ietf.org/shadow.html. Note that the first paragraph of this section is a meaningless bureaucratic requirement of the IESG. It is provided so as to satisfy those bureaucratic requirements, and serves no other purpose whatever. No assumption should be made that the author(s) have assented to any of it. Information as to any intellectual property rights, beyond the right to redistribute this document and make use of it for the purposes of an Internet Draft, should be sought in other parts of this document. Distribution of this memo is unlimited. Simpson expires in six months [Page i] DRAFT Secret Exchange March 1999 Copyright Notice Copyright (C) William Allen Simpson (1995,1998-1999). All Rights Reserved. Abstract Photuris is a session-key management protocol. Extensible Messages are provided to enable future implementation changes without affecting the basic protocol. The Secret Exchange messages provide the capability to create ephemeral symmetric secrets between parties. Simpson expires in six months [Page ii] DRAFT Secret Exchange March 1999 1. Introduction The packet format and basic facilities are already defined for Photuris [RFC-2522]. In addition to establishing session-keys, Photuris is easily capable of generating high quality unpredictable secrets. This facility can be useful to augment or expand lower quality user passwords, and to substitute for computationally expensive public-key operations. Existing identities are exchanged between the parties, and new identities with symmetric secrets are created. Upon successful completion of the Photuris exchange, the existing access permissions and other delegated authorizations are associated with the corresponding substitute identities. 1.1. Terminology In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "required", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC-2119]. nonce A value that is not used more than once for the same purpose. The value is recommended to be generated by a cryptographically random method, which may be concatenated with a timestamp or sequence number. Party Secret Index (PSI) A number that indicates a particular symmetric secret. The value is recommended to be generated by a cryptographically random method. The use of this value is orthogonal to usage of similar values by other related security protocols, such as the Security-Parameters-Index (SPI). That is, the same value MAY be used by multiple protocols to concurrently indicate different Security Association parameters. 1.2. LifeTimes Each PSI identity and secret has an associated LifeTime, specified by the PSI Owner (sender). This PSI LifeTime (PSILT) is usually long- lived (typically 4 to 8 weeks), but it MUST NOT be greater than the lifetime of original identity used in its creation. Simpson expires in six months [Page 1] DRAFT Secret Exchange March 1999 There is no requirement that a long LifeTime be accepted by the PSI User. A PSI identity may be used only for the current Photuris exchange, or be purged at any time. Whenever a new PSI identity is established, a common implementation technique is to immediately expire all previous identities associated with the same pair of original identities. However, selecting randomly among several PSIs to expire might provide some defense against traffic analysis. When a PSI identity expires (or is replaced by a newer value), existing Photuris exchanges and any unexpired derived SPIs are not affected. Although PSI identities and secrets can be stored in an external database in the same manner as other long-lived identities and secrets, care MUST be taken that PSI identities and secrets are purged as they expire, and are not retained in backup storage. The paranoid operator might store the data in a memory-only cryptographic file system. 1.3. Value Exchange Parameter Selection Photuris exchanges employing the Secret Exchange MUST select Value Exchange parameters with at least the equivalent cryptographic strength of the identities that will be utilized. Later exchanges MAY use less strength to reduce computational cost, relying on the quality of the PSI secrets for protection. Implementations enjoying party privacy protection SHOULD select the greatest cryptographic strength available. This inhibits discovery and linking of the original identities of the parties with the substitute PSI identities in later exchanges. Simpson expires in six months [Page 2] DRAFT Secret Exchange March 1999 2. Secret Exchange The Secret Exchange will occur following the usual Value Exchange: Initiator Responder ========= ========= Cookie_Request -> <- Cookie_Response Value_Request -> <- Value_Response [generate shared-secret from exchanged values] Frequently, the Secret Exchange will occur before the Identification Exchange: Initiator Responder ========= ========= Secret_Request -> make PSI identify self authenticate make privacy key(s) mask/encrypt message <- Secret_Response make PSI identify self generate nonce authenticate make privacy key(s) mask/encrypt message Identity_Request -> make SPI pick SPI attribute(s) generate nonce authenticate make privacy key(s) mask/encrypt message [make PSI secret-keys in each direction] <- Identity_Response [make SPI session-keys in each direction] Alternatively, the Secret Exchange can occur in the middle of the Identification Exchange: Simpson expires in six months [Page 3] DRAFT Secret Exchange March 1999 Initiator Responder ========= ========= Identity_Request -> <- Secret_Request Secret_Response -> [make PSI secret-keys in each direction] <- Identity_Response [make SPI session-keys in each direction] The exchange of messages is ordered, although the formats and meanings of the messages are similar in each direction. The messages are easily distinguished by the parties themselves, by examining the Message and Identification fields. Nota Bene: A Secret_Request may be sent by either the Initiator or Responder. The terms Primary and Secondary are used for the Secret Exchange parties. 2.0.1. Send Secret_Request The Primary chooses an appropriate Identification, the PSI and PSILT, calculates the Verification, and masks the message using the Privacy-Method indicated by the current Scheme-Choice. The Primary also starts a retransmission timer. If no valid Secret_Response arrives within the time limit, its previous Secret_Request is retransmitted for the remaining number of Retransmissions. When Retransmissions have been exceeded, if a Bad_Cookie message has been received during the exchange, the Primary SHOULD begin the Photuris exchange again by sending a new Cookie_Request. 2.0.2. Receive Secret_Request The Secondary validates the pair of Cookies, the Padding, the Verification, and the Identification. - When an invalid/expired cookie is detected, a Bad_Cookie message is sent. - After unmasking, when invalid Padding is detected, or the Verification format is invalid, the message is silently discarded. Simpson expires in six months [Page 4] DRAFT Secret Exchange March 1999 - When the message verification fails, or an invalid Identification format is detected, or external signature validation fails, or other authorization policy failures are indicated, a Verification_Failure message is sent. - Whenever such a problem is detected, the Security Association is not established; the implementation SHOULD log the occurance, and notify an operator as appropriate. When the message is valid, the Secondary returns a Secret_Response. The Secondary keeps a copy of the incoming Secret_Request values, and its Secret_Response. If a duplicate Secret_Request is received, it merely resends its previous Secret_Response, and takes no further action. Implementation Notes: Validation of message formats MUST take place before determination of signatures and authorization. Such determination may take a substantial amount of time. To improve performance, an implementation can cache the public keys for the issuers that frequently sign end-user certificates. These cached public keys can be used to verify the final certificate, and avoid the cost of verifying each certificate in the chain. 2.0.3. Send Secret_Response The Secondary chooses an appropriate (optional) Identification, the PSI and PSILT, generates an appropriate Secret-Value for the Secret_Request Identity-Choice, calculates the Verification, and masks the message using the Privacy-Method indicated by the current Scheme-Choice. 2.0.4. Receive Secret_Response The Primary validates the pair of Cookies, the Padding, the Verification, the Secret-Value, and the (optional) Identification. - When an invalid/expired cookie is detected, the message is silently discarded. - After unmasking, when invalid Padding is detected, or the Verification format is invalid, or the Secret-Value format is Simpson expires in six months [Page 5] DRAFT Secret Exchange March 1999 invalid, the message is silently discarded. - When the message verification fails, or an invalid Identification format is detected, or external signature validation fails, or other authorization policy failures are indicated, a Verification_Failure message is sent. - Whenever such a problem is detected, the Security Association is not established; the implementation SHOULD log the occurance, and notify an operator as appropriate. - Once a valid message has been received, later Secret_Responses with both matching cookies are also silently discarded, until a new Cookie_Request is sent. When the message is valid, the Primary sends an appropriate Identification Message. Implementation Notes: Validation of message formats MUST take place before determination of signatures and authorization. Such determination may take a substantial amount of time. To improve performance, an implementation can cache the public keys for the issuers that frequently sign end-user certificates. These cached public keys can be used to verify the final certificate, and avoid the cost of verifying each certificate in the chain. Simpson expires in six months [Page 6] DRAFT Secret Exchange March 1999 2.1. Secret_Request +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initiator-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Responder-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message | LifeTime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Party-Secret-Index | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | ~ Verification ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identity-Choice | | + + + + + + + + + + + + + + + + + + | | ~ Identification ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Initiator-Cookie 16 bytes. Copied from the Value_Request. Responder-Cookie 16 bytes. Copied from the Value_Request. Message 6 LifeTime 3 bytes. The number of seconds remaining before the indicated PSI expires. The value zero indicates that the PSI is used for only this Identification Exchange. Party-Secret-Index (PSI) 4 bytes. The PSI to be used for this party in the Identification Exchange. The value MUST NOT be zero. Verification Variable Precision Integer, or other format indicated by the current Scheme-Choice. The calculation of the value is described in Simpson expires in six months [Page 7] DRAFT Secret Exchange March 1999 "Integrity Verification". The field may be any integral number of bytes in length. It does not require any particular alignment. The 32-bit alignment shown is for convenience in the illustration. Identity-Choice 2 or more bytes. An identity attribute is selected from the list of Offered-Attributes sent by the peer. The field may be any integral number of bytes in length, as indicated by its Length field. It does not require any particular alignment. The 16-bit alignment shown is for convenience in the illustration. Identification Variable Precision Integer, or alternative format indicated by the Identity-Choice. See the "Additional Attributes" for details. The field may be any integral number of bytes in length. It does not require any particular alignment. The 32-bit alignment shown is for convenience in the illustration. Padding 8 to 255 bytes. This field is filled up to at least a 128 byte boundary, measured from the beginning of the message. The number of pad bytes are chosen randomly. In addition, when a Privacy-Method indicated by the current Scheme-Choice requires the plaintext to be a multiple of some number of bytes (the block size of a block cipher), this field is adjusted as necessary to the size required by the algorithm. Self-Describing-Padding begins with the value 1. Each byte contains the index of that byte. Thus, the final pad byte indicates the number of pad bytes to remove. For example, when the unpadded message length is 120 bytes, the padding values might be 1, 2, 3, 4, 5, 6, 7, and 8. The portion of the message after the PSI field is masked using the Privacy-Method indicated by the current Scheme-Choice. Simpson expires in six months [Page 8] DRAFT Secret Exchange March 1999 The fields following the PSI are opaque. That is, the values are set prior to masking (and optional encryption), and examined only after unmasking (and optional decryption). 2.1.1. Integrity Verification The Secret_Request is authenticated using the Validity-Method indicated by the current Scheme-Choice. The Verification value is calculated prior to masking (and optional encryption), and verified after unmasking (and optional decryption). The Validity-Method authentication function is supplied with two input values: - the integrity-key, - the data to be verified (as a concatenated sequence of bytes). The resulting output value is stored in the Verification field. The Scheme-Choice specified Key-Generation-Function is used to create a special integrity-key. This function is calculated over the computed shared-secret. The verification data consists of the following concatenated values: + the Initiator Cookie, + the Responder Cookie, + the Message, LifeTime and PSI fields, + the Identity-Choice and Identification, + the Padding. Implementation Notes: The exact details of the Identification included in the Verification calculation are dependent on the corresponding Identity-Choice. Failure to find an Identification in either an internal or external database results in the same Verification_Failure message as failure of the verification computation. Simpson expires in six months [Page 9] DRAFT Secret Exchange March 1999 2.2. Secret_Response +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initiator-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Responder-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message | LifeTime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Party-Secret-Index | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | ~ Verification ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Secret-Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Identity-Choice) | | + + + + + + + + + + + + + + + + + + | | ~ (Identification) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Initiator-Cookie 16 bytes. Copied from the Secret_Request. Responder-Cookie 16 bytes. Copied from the Secret_Request. Message 5 LifeTime 3 bytes. The number of seconds remaining before the indicated PSI expires. The value zero indicates that the PSI is used for only this Identification Exchange. Party-Secret-Index (PSI) 4 bytes. The PSI to be used for this party in the Identification Exchange. The value MUST NOT be zero. Also, the value SHOULD NOT equal the Simpson expires in six months [Page 10] DRAFT Secret Exchange March 1999 PSI from the Secret_Request. Verification Variable Precision Integer, or other format indicated by the current Scheme-Choice. The calculation of the value is described in "Integrity Verification". The field may be any integral number of bytes in length. It does not require any particular alignment. The 32-bit alignment shown is for convenience in the illustration. Secret-Value Variable Precision Integer, or alternative format indicated by the Secret_Request Identity-Choice. Used for calculating a pair of symmetric secret- keys between the parties. The field may be any integral number of bytes in length, as indicated by its Size field. It does not require any particular alignment. The 32-bit alignment shown is for convenience in the illustration. (Identity-Choice) 2 or more bytes. An identity attribute is selected from the list of Offered-Attributes sent by the peer. This field may be omitted. See "During Identification Exchange". The field may be any integral number of bytes in length, as indicated by its Length field. It does not require any particular alignment. The 16-bit alignment shown is for convenience in the illustration. (Identification) Variable Precision Integer, or alternative format indicated by the Identity-Choice. See the "Additional Attributes" for details. This field may be omitted. See "During Identification Exchange". The field may be any integral number of bytes in length. It does not require any particular alignment. The 32-bit alignment shown is for convenience in the illustration. Simpson expires in six months [Page 11] DRAFT Secret Exchange March 1999 Padding 8 to 255 bytes. This field is filled up to at least a 128 byte boundary, measured from the beginning of the message. The number of pad bytes are chosen randomly. In addition, when a Privacy-Method indicated by the current Scheme-Choice requires the plaintext to be a multiple of some number of bytes (the block size of a block cipher), this field is adjusted as necessary to the size required by the algorithm. Self-Describing-Padding begins with the value 1. Each byte contains the index of that byte. Thus, the final pad byte indicates the number of pad bytes to remove. For example, when the unpadded message length is 120 bytes, the padding values might be 1, 2, 3, 4, 5, 6, 7, and 8. The portion of the message after the PSI field is masked using the Privacy-Method indicated by the current Scheme-Choice. The fields following the PSI are opaque. That is, the values are set prior to masking (and optional encryption), and examined only after unmasking (and optional decryption). 2.2.1. Before Identification Exchange When the Secret Exchange occurs before the Identification Exchange, the optional Identity-Choice and Identification fields are included in the Secret_Response. The subsequent Identification_Request is modified. The Identification field is replaced by a Secret-Value field. (The Identity-Choice field remains in place.) The derived Primary Secret Identity is used internally instead of the usurped Identification field, with the associated Primary secret-key. The derived Secondary Secret Identity MUST be used in the Identification_Response, with the associated Secondary secret-key. Simpson expires in six months [Page 12] DRAFT Secret Exchange March 1999 2.2.2. During Identification Exchange When the Secret Exchange occurs during the Identification Exchange, the optional Identity-Choice and Identification fields are excluded from the Secret_Response. Instead, the values are taken from the Identification_Request, and the secret-nonce is the associated generation-key. The derived Primary Secret Identity MUST be used in the Identification_Response, with the associated Primary secret-key. The derived Secondary Secret Identity is unused in this exchange, but MAY be used in a later exchange. 2.2.3. Integrity Verification The Secret_Response is authenticated using the Validity-Method indicated by the current Scheme-Choice. The Verification value is calculated prior to masking (and optional encryption), and verified after unmasking (and optional decryption). The Validity-Method authentication function is supplied with two input values: - the integrity-key, - the data to be verified (as a concatenated sequence of bytes). The resulting output value is stored in the Verification field. The Scheme-Choice specified Key-Generation-Function is used to create a special integrity-key. This function is calculated over the following concatenated values: + the Secret_Request Verification field, + the computed shared-secret. The verification data consists of the following concatenated values: + the Initiator Cookie, + the Responder Cookie, + the Message, LifeTime and PSI fields, + the Secret-Value, + the Identity-Choice and Identification (optional), + the Padding. Simpson expires in six months [Page 13] DRAFT Secret Exchange March 1999 If the verification fails, the users are notified, and a Verification_Failure message is sent, without adding any PSI identities. On success, normal operation begins with the remainder of the Identification Exchange. The Secret Exchange depends upon the Identification Exchange for ultimate verification. When later verification fails, the PSI secret-keys MUST be discarded. Implementation Notes: The exact details of the Identification and Secret-Value included in the Verification calculation are dependent on the corresponding Identity-Choices. Failure to find an Identification in either an internal or external database results in the same Verification_Failure message as failure of the verification computation. 2.3. Secret-Nonce A secret-nonce is formed as indicated by the Identity-Choice and Identification specified in the Secret_Request (and optionally in the Secret_Response). Asymmetric Identity Attribute The Secret-Value contains the nonce encoded by the specified public-key. Symmetric Identity Attribute The Value part of the Secret-Value is concatenated to (followed by) the existing symmetric secret-key. Regardless of the internal representation of the secret-nonce, when used in calculations it is in the same form as the Value part of a Variable Precision Integer: - most significant byte first. - bits used are right justified within byte boundaries. - any unused bits are in the most significant byte. - unused bits are zero filled. The secret-nonce does not include a Size field. Simpson expires in six months [Page 14] DRAFT Secret Exchange March 1999 2.4. Secret-Key Computation Each pair of PSI values is used to generate a corresponding pair of symmetric secret-keys (one for each party). The Scheme-Choice specified Key-Generation-Function is used to create the secret-key for each party. This function is calculated over the following concatenated values: + the Initiator Cookie, + the Responder Cookie, + the Owner Message, LifeTime and PSI, + the Peer Message, LifeTime and PSI, + the Owner secret-nonce, + the Peer secret-nonce, + the computed shared-secret. Since the order of the Owner and Peer fields is different in each direction, the resulting secret-key will usually be different in each direction. 2.5. Secret Identities The pair of PSI values also identifies the secret-keys. These identities can be used with a symmetric identity attribute in any subsequent Identification message. The Primary identity is the Secret_Request PSI value, concatenated to (followed by) the Secret_Response Verification value. The Secret_Request LifeTime is used as the LifeTime. The Secondary identity is the Secret_Response PSI value, concatenated to (followed by) the Secret_Response Verification value, concatenated to (followed by) the Secret_Request PSI value. The Secret_Response LifeTime is used as the LifeTime. Simpson expires in six months [Page 15] DRAFT Secret Exchange March 1999 3. Additional Attributes The attribute format and basic facilities are already defined for Photuris [RFC-2522]. These optional attributes are specified separately, and no single implementation is expected to support all of them. Nota Bene: Support is always required for the [RFC-2522] "MD5-IPMAC" (#5) attribute for the Secret_Request Identity-Choice. This document defines the following values: Use Type I 27 DNS Key RR I 28 OpenPGP I 29 X.509 I Identity-Choice 3.0.1. Authentication These attributes are never used as an AH or ESP Attribute-Choice. 3.0.2. Verification These attributes are never used for [RFC-2522] "Identity Verification" or "Validity Verification". Instead, the Secret Exchange occurs to associate a pair of symmetric secrets with the Identification. Simpson expires in six months [Page 16] DRAFT Secret Exchange March 1999 3.1. DNS Key Resource Record +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute | Length | Power | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute 27 Length 2 Power 1 byte. The public/private-key bits supported, expressed as a power of two. When listed as an Offered-Attribute, the Power is set to the maximum supported. As a minimum, all implementations MUST support value 10 (1024-bit keys). When selected as an Attribute-Choice, the Power is set to the actual value to be used. Algorithm 1 byte. An algorithm supported. See [RFC-2535] for details. Examples include: 1 [RFC-2537] RSA with MD5. 3 [RFC-2536] DSA with SHA1. When more than one Algorithm is supported, multiple attributes are listed in the Offered- Attributes. When this attribute is implemented, [RFC-2535] requires support for Algorithm #3 [RFC-2536], which SHOULD be present in every Offered-Attributes list. 3.1.1. Asymmetric Identification When selected as an Identity-Choice, the immediately following Identification field contains the binary form of the DNS Key Resource Record. The domain name is fully expanded (no name compression via pointers). Any Key RR that is available for authentication (the Authentication flag bit is clear) MAY be used. Currently, no Simpson expires in six months [Page 17] DRAFT Secret Exchange March 1999 specific Key Protocol value has been defined for Photuris. It is recommended that DNSSEC (#3), email (#2), and TLS (#1) keys be used in preference to Oakley/IPSEC (#4) keys that are specific to another session-key management protocol. No DNS Signature Resource Records are included with the Identification. Valid Identifications and corresponding signature certificates are preconfigured by the parties, or maintained in external databases. The Identification value is not contained within a Variable Precision Integer (VPI). The Key RR elements are parsed by the implementation to determine the end of the Identification field. The returned Secret-Value consists of a nonce encoded by the specified public-key, of the form determined by the DNS Key algorithm. The result is contained within a Variable Precision Integer (VPI). 3.2. OpenPGP Identification +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute | Length | Power | Version ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | +-+-+-+-+-+-+-+-+ Attribute 28 Length 3 Power 1 byte. The public/private-key bits supported, expressed as a power of two. When listed as an Offered-Attribute, the Power is set to the maximum supported. As a minimum, all implementations MUST support value 10 (1024-bit keys). When selected as an Attribute-Choice, the Power is set to the actual value to be used. Version 2 bytes. A Public Key Packet version supported. See [RFC-2440] for details. Versioning is complicated by the number of Simpson expires in six months [Page 18] DRAFT Secret Exchange March 1999 algorithms supported. For negotiation, the version and algorithm combinations are treated as a single quantity. Examples include: 0x0301 RSA in PGP 2.6.x. 0x0401 RSA in PGP 5.x. 0x0403 RSA in PGP 5.x, signature only. 0x0411 DSA in PGP 5.x. 0x0414 ElGamal in PGP 5.x, encrypt or sign. When more than one Version is supported, multiple attributes are listed in the Offered-Attributes. When this attribute is implemented, [RFC-2440] requires support for Version #0411, which SHOULD be present in every Offered- Attributes list. Due to the widespread use of PGP 2.6.x, this specification also recommends support for Version #0301. 3.2.1. Asymmetric Identification When selected as an Identity-Choice, the immediately following Identification field contains a PGP "Public Key Packet". PGP "User ID Packet", "Signature Packet", or sub-packet elements MUST NOT be included in the Identification. Valid Identifications and corresponding signature certificates are preconfigured by the parties, or maintained in external databases. The Identification value is not contained within a Variable Precision Integer (VPI). The PGP elements are parsed by the implementation to determine the end of the Identification field. The returned Secret-Value consists of a nonce encoded by the specified public-key, of the form determined by the OpenPGP algorithm. The result is contained within a Variable Precision Integer (VPI). Nota Bene: The PGP Multi-Precision Integer (MPI) is very similar to the Variable Precision Integer (VPI). However, the Size field is not extensible, and PGP library functions truncate leading significant zeroes. Simpson expires in six months [Page 19] DRAFT Secret Exchange March 1999 3.3. X.509 Identification +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute 29 Length 0 Future extensions to this attribute may add parameter values. This will be indicated by a non-zero value. 3.3.1. Asymmetric Identification When selected as a Identity-Choice, the immediately following Identification field contains an X.509 "TBSCertificate", conforming to the profile specified in [RFC-2459]. Full X.509 certificates with signatures MUST NOT be included in the Identification. Valid Identifications and corresponding signature certificates are preconfigured by the parties, or maintained in external databases accessed by [RFC-2510 and RFC-2511]. The Identification value is not contained within a Variable Precision Integer (VPI). The X.509 elements are parsed by the implementation to determine the end of the Identification field. The returned Secret-Value consists of a nonce encoded by the specified public-key, of the form determined by the subjectPublicKey algorithm. The result is contained within a Variable Precision Integer (VPI). Simpson expires in six months [Page 20] DRAFT Secret Exchange March 1999 A. DSA Secret-Value When using asymmetric public/private-key identities, this protocol requires the passing of a nonce encoded by the specified public- key. While this has a natural fit with RSA, DSA was not intended for public-key encryption of random values. However, it is possible to use the DSA parameters, bypassing the signature function, given a sufficiently generic programming interface. A brief description can be found in [Schneier95]. Using the OpenSSL library, Operational Considerations Each party configures a list of known identities and validation certificates. In addition, each party configures local policy that determines what access (if any) is granted to the holder of a particular identity. For example, the party might allow anonymous FTP, but prohibit Telnet. Such considerations are outside the scope of this document. Security Considerations Keys retrieved from external sources should not be trusted without independent verification by the party. When using asymmetric public/private-key identities, it is possible that an active interception and modification attack (sometimes called "Monkey in the Middle" or MITM) will use entirely valid certificates. Operators should be suspicious when the peer identities are all certified by a single entity, such as the regional security agency equivalent. This attack can only be prevented through rigorous authorization policy enforcement. Simpson expires in six months [Page 21] DRAFT Secret Exchange March 1999 Acknowledgements William Simpson was responsible for the packet formats, additional message types, editing and formatting. Robert W Baldwin provided text for X.509 Certificates and other implementation details. Steven Bellovin suggested enhancing existing symmetric secret-keys with greater entropy. Hilarie Orman suggested adding secret "nonces" to session-key generation for asymmetric public/private-key identity methods. References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, Harvard University, March 1997. [RFC-2440] [RFC-2459] [RFC-2510] [RFC-2511] [RFC-2522] Karn, P., and Simpson, W., "Photuris: Session-Key Management Protocol", March 1999. [RFC-2535] [RFC-2536] [RFC-2537] [Schneier95] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. Simpson expires in six months [Page 22] DRAFT Secret Exchange March 1999 Contacts Comments about this document should be discussed on the photuris@adk.gr mailing list. Questions about this document can also be directed to: William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 wsimpson@UMich.edu wsimpson@GreenDragon.com (preferred) Full Copyright Statement Copyright (C) William Allen Simpson (1995,1998-1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, except as required to translate it into languages other than English. This document and the information contained herein is provided on an "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Simpson expires in six months [Page 23]