Network Working Group Phil Karn Internet Draft Qualcomm W A Simpson DayDreamer expires in six months July 1995 The Photuris Session Key Management Protocol draft-ietf-ipsec-photuris-02.txt Status of this Memo This document is a submission to the IP Security Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ipsec@ans.net mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. 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 a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Abstract Photuris [1] is an experimental session-key management protocol intended for use with the IP Security Protocols (AH and ESP) in a point-to-point mode. Karn & Simpson expires in six months [Page i] DRAFT Photuris July 1995 Photuris is still in the early design stages and has not yet been completely specified. It is hoped that this draft will stimulate discussion about the merits of the design philosophy. Karn & Simpson expires in six months [Page ii] DRAFT Photuris July 1995 1. Introduction The ultimate goal of Internet Security is to facilitate direct IP connectivity between sensitive hosts and users across the Internet. Users must have confidence in every Internet Security component, including key management. Users will rely on Internet Security to protect the confidentiality of the traffic they send across the Internet and depend on it to block unauthorized external access to their internal hosts and networks. Without this confidence, users may erect barriers that impede legitimate use of the Internet, or forego the Internet entirely. Internet Security does not place any significance on easily forged IP Source addresses. It relies instead on proof of possession of secret knowledge: that is, a cryptographic key. Photuris combines Diffie-Hellman key exchange with authentication to provide perfect forward secrecy, as defined by Diffie [2]. The protocol is also designed to thwart certain types of denial of service attacks on host resources. This draft assumes familiarity with the Diffie-Hellman public-key algorithm. A good description can be found in [5]. 1.1. Terminology Initiator The key establishment party which sends the first Photuris session request. public/private key-pair A pair of keys, one of which is publically distributable, the other of which is kept secret. public-value As used in this document, the publically distributable value used in the D-H exchange to calculate a shared-secret. Responder The key establishment party which receives the first Photuris session request. shared-secret As used in this document, the calculated result of the D-H exchange. Karn & Simpson expires in six months [Page 1] DRAFT Photuris July 1995 secret-key A single key which is not publically distributable and not part of a public/private key-pair. Security Association A collection of parameters describing the security relationship between two nodes. These parameters include the transform (including algorithm and algorithm mode), the key(s) (such as a secret-key, or appropriate public/private key-pair), and possibly other information such as sensitivity labelling. For further details, see [A-SA]. 1.2. Use of Public-Key Cryptography Photuris is based on public-key cryptography, specifically Diffie- Hellman key exchange. Exchange of D-H public-values based on private/secret values results in a mutual shared-secret between the parties. This shared-secret can be used on its own, or to generate a series of session-keys for authentication and encryption of subsequent traffic. Widespread deployment and use of an Internet Security protocol is possible without public-key cryptography. For example, Kerberos [6] can generate host-pair keys for use in Internet Security, much as it now generates session-keys for use by encrypted telnet and other "kerberized" applications. The Kerberos model has some widely recognized drawbacks. Foremost is the requirement for a highly available on-line Key Distribution Center (KDC), with a database containing every principal's secret- key. This carries significant security risks. Public-key cryptography enables decentralization. Entities generate session-keys without real-time communication with any other party. 1.3. Authentication It has been shown in [DOW92] that key exchange must be coupled to authentication. Photuris supports the use of a variety of digital signature methods. The Photuris messages include selection of authentication algorithms, and facilitate the exchange of any chosen certificate type. The DSS and RSA are examples of digital signatures which will provide strong Karn & Simpson expires in six months [Page 2] DRAFT Photuris July 1995 authentication. Details of DSS, RSA, and other signature algorithms may be found in [5]. 1.4. Defense against Clogging Protecting sensitive data on the Internet against compromise -- either by interception or by unauthorized access -- is necessary, but not sufficient. The computing resources themselves must also be protected against malicious attack or sabotage. To grant access to authorized users regardless of location, it must be possible to cheaply detect and discard bogus datagrams. Otherwise, an attacker intent on sabotage might rapidly send datagrams to exhaust the host's CPU or memory resources. Using Internet Security authentication facilities, when a datagram does not pass an authentication check, it can be discarded without further processing. This is easily done with manual (null) key management between trusted hosts at relatively little cost, given the speed of cryptographic hash functions compared to public-key algorithms. Unfortunately, such a trusted host will have only a fixed number of keys available. The keys will tend to have long lifetimes. This carries significant security risks. Automatic key management is necessary to generate keys between parties without prior arrangement. But, there is a potential Achilles heel in the key management protocol. Because of their use of CPU-intensive operations, such as modular exponentiation, key management schemes based on public-key cryptography are vulnerable to resource clogging attacks. Although a complete defense against such attacks is impossible, a simple feature makes them much more difficult. Photuris exchanges a "cookie" before initiating public-key operations, thwarting the saboteur from using random IP Source addresses. The simple validation of this cookie uses the same level of resources as other Internet Security authentication mechanisms. This limits an attacker to methods which intercept the cookie, forcing the attacker to: 1) use her own IP address, Karn & Simpson expires in six months [Page 3] DRAFT Photuris July 1995 2) gain access to a transmission link to a subnet whose addresses she appropriates, or 3) subvert Internet routing for the same purpose. The first option allows the target to detect and filter out such attacks, and significantly increases the likelihood of identifying the attacker. The latter two options are much more difficult than merely sending large numbers of datagrams with randomly chosen IP Source addresses from an arbitrary point on the Internet. The cookie does not protect against an observer which can copy a valid cookie, or an interceptor which can modify or substitute another cookie. These attacks are mitigated through using time- variant cookies, and the elimination of receiver state during initial exchanges of the protocol. 1.5. Perfect Forward Secrecy Many security breaches in cryptographic systems have been facilitated by designs which generate traffic-encrypting keys (or their equivalents) well before they are needed, and then keep them around longer than necessary. This creates many opportunities for compromise, especially by insiders. A carefully designed public-key system can avoid this problem. The rule is to avoid using any long-lived keys (such as an RSA key- pair) to encrypt session-keys or actual traffic. Such keys should be used solely for authentication purposes. All keys for traffic encryption should be randomly generated immediately before use, and then destroyed immediately after use, so that they cannot be recovered. Photuris uses a combination of Diffie-Hellman (for key exchange) and digital signature authentication, as follows: 1. Agree on a shared-secret using the Diffie-Hellman algorithm. 2. Authenticate the Diffie-Hellman exchanges with a digital signature algorithm, such as RSA or DSS. This authenticates the parties to each other, thwarting the "man in the middle" active attack against Diffie-Hellman. When the shared-secret generated in step 1 is eventually destroyed, it is unrecoverable. The generating information is not based on any other stored information. Karn & Simpson expires in six months [Page 4] DRAFT Photuris July 1995 Theft of the private/secret key used to sign the exchanges in step 2 would allow the thief to impersonate the party in future conversations, but it would not decode any past traffic that might have been recorded. 1.6. Traffic Anonymity As noted above, a fundamental role of a key management protocol is to verify the identities of the communicating parties to each other. One would often like to deny this information to an eavesdropper, especially when this would reveal the location of a user. Although each datagram carries a cleartext IP Destination address, the ultimate destination could be hidden by "laundering" it through an encrypted tunnel. A user's IP Source address could be hidden in the same manner. If the address has been dynamically allocated, it provides no useful information to an eavesdropper. This leaves the identifying authentication information that the user sends during key exchange. The identification can be easily protected in the Photuris protocol by encrypting the digital signature exchanges with the key just established with Diffie- Hellman. This keeps a passive eavesdropper from learning the identities of the parties by intercepting possible exchanges of public keys and certificates, or by checking the signatures against a known database of public keys. The scheme is not foolproof. By posing as the Responder, an active attacker could trick the Initiator into revealing her identity. However, this active attack is considerably more difficult than passive vacuum-cleaner monitoring. Unless the attacker can steal the private/secret key belonging to the Responsder, the Initiator will discover the deception when checking the digital signature of the key exchange. 1.7. Security Parameters In addition to the key(s) used to authenticate, encrypt or decrypt the payload, the key management mechanism is used to determine a number of parameters for each Security Association between the communicating parties. This includes the particular authentication and/or encryption transforms. Karn & Simpson expires in six months [Page 5] DRAFT Photuris July 1995 The key management implementation usually maintains a table containing the several parameters for each current Security Association. The implementation needs to access that security parameter table to determine how to process each datagram. The Security Parameters Index (SPI) is assigned by the entity controlling the IP Destination address. A session between two parties will normally have two SPI values (one in each direction). The parties use the combination of SPI and IP Destination to distinguish the correct association. The selection mechanism used for the SPI is implementation dependent. However, selection of a random value can help prevent attacks which depend on a predicatable sequence of values. To provide protection against an interceptor which can modify or substitute another SPI, the SPI is used in creating a separate session-key in each direction. While alteration of the SPI will interrupt communication, the attacker will gain no additional information. 1.8. Multicast Support Key management is more difficult in a multicast environment. Senders to a multicast group may share common a Security Parameters Index, if all communications are using the same security configuration parameters. In this case, the receiver only knows that the message came from a node knowing the SPI for the group, and cannot authenticate which member of the group sent the datagram. Multicast groups may also use a separate SPI value for each Source. If each sender is keyed separately and asymmetric algorithms are used, data origin authentication is also provided. A given Destination is not necessarily in control of the selection process. In the case of multicast groups, a single node or cooperating subset of the multicast group may work on behalf of the entire group to set up a Security Association. The author is also open to suggestions on how multicast capability might be added to Photuris, without compromising its fundamental features. Karn & Simpson expires in six months [Page 6] DRAFT Photuris July 1995 2. Protocol Description The Photuris protocol consists of several simple phases: 1. A "cookie" exchange to guard against simple flooding attacks with bogus IP Source addresses. 2. A Diffie-Hellman exchange to establish a session-key for conventional authentication or encryption. 3. An exchange of digital signatures on the Diffie-Hellman messages that were sent in phase 2, to verify their integrity and the identities of the two parties. This exchange may be encrypted to protect the privacy of the parties. 4. Once an initial Security Association has been established, regular operation of the Internet Security protocol begins encryption and/or authentication of user datagrams. 5. Additional messages may be exchanged to periodically change the session-key and to establish new security parameters. Either party may initiate a session at any time. For example, the Initiator need not be a "caller" in a telephony link. The Initiator is responsible for recovering from all message losses by retransmission. The Responder remains stateless until a session- key has been created. Once the session-key calculation has been initiated, the Responder cooperates in creating a second serendipitous session-key, in order to save the effort of another round of key establishment in the other direction. When both parties initiate Photuris key establishment concurrently, or one party initiates more than one Photuris session, the UDP Ports keep the sessions separate. This results in more than one SPI for each Destination. There is no requirement that all such SPIs be used. The sender chooses the SPI for each transmission. Old SPI values simply expire after a short period of time (typically 30 seconds), and are purged sometime later (typically 10 minutes). LifeTimes are implementation dependent. Should an expired SPI (which is not yet purged) arrive from an IP Source, a new Cookie_Request is sent, and the Photuris exchange begins again. Karn & Simpson expires in six months [Page 7] DRAFT Photuris July 1995 Implementation Notes: To provide user-oriented keying, or create multiple Security Associations with different parameters, the sender can initiate multiple Photuris exchanges, or send a Key_Change (described later). It is the responsibility of the sender to assign and segregate the different session-keys. The Destination SHOULD be capable of maintaining multiple SPI values for each Source. 2.1. UDP All Photuris messages use the User Datagram Protocol header [RFC- 768]. The Initiator sends to UDP Destination Port 468. The Responder reverses the IP Source and Destination, and the UDP Source and Destination Ports. The UDP checksum is required. Any message with an incorrect or zero UDP checksum is silently discarded. 2.2. Variable Precision Numbers Many of the message fields require a value which may vary in the number of bits. These bits may not make up an integral number of octets. Each variable precision number is composed of two parts. Size 2 octets. Number of bits used in the value. Always transmitted most significant octet first. Value variable. The bits used are right justified and zero filled on octet boundaries; that is, any unused bits are in the most significant octet. Always transmitted most significant octet first. 2.3. Attributes Selection among several different attributes is needed to enable future implementation changes without affecting the basic protocol. Each party specifies a list of the attributes supported. Karn & Simpson expires in six months [Page 8] DRAFT Photuris July 1995 The attribute list includes authentication, compression, encryption and signature types. These are mixed in the same list for simplicity. The implementation can easily distinguish between the separate uses of each supported attribute. This is not a "negotiation". The Destination indicates the attributes it supports in order of preference, and the Source selects from that list. Each party selects an authentication function from the list of mechanisms supported by the other party. Authentication policy is in the receiver direction. Only the receiver can determine that arriving traffic is authentic. It indicates its need for authentication by including authentication transforms, and/or authenticated encryption transforms, in its transform list. It enforces the authentication through the simple expedient of dropping all datagrams that don't arrive with authentication. Each party additionally selects an encryption mode (if any) according to its own local policy database. Encryption policy is in the transmitter direction. Only the sender knows whether each datagram needs privacy protection. If no, it picks an authentication-only algorithm SPI. If yes, it picks an encryption algorithm SPI. Note that the authentication, compression, encryption and signature mechanisms, as well as the encapsulation mode (if any), need not be the same in both directions. 2.4. Modular Exponentiation Groups The original Diffie-Hellman technique specified modular exponentiation. A public-value is generated using a generator (g), raised to a private/secret exponent (x), modulo a prime (p). (g**x) mod p When two of these public-values are exchanged between parties, the parties can calculate a shared-secret value between themselves. Each modular exponentiation prime (p) must have the property that both p and (p-1)/2 are prime. A small set of such recommended strong primes for use as Photuris moduli are specified. Use of a very limited number of moduli (preferably one) has one minor and two very significant advantages: Karn & Simpson expires in six months [Page 9] DRAFT Photuris July 1995 Overhead Avoiding the overhead of sending the full modulus. Prime and Generator Pair Selection Discovery of strong primes is extremely computationally intensive, and practically impossible for commercially available processors to find in a reasonable interactive time. Thus, the primes used will be well-known, and embedded in the implementations. The generator (g) should be chosen such that the secret exponents will generate all possible public exponential values, evenly distributed throughout the range, without cycling through a smaller subset. Such a generator is called a "primitive root" (which is trivial to find when p is strong) [!!! reference]. When the strong prime and generator pair are well chosen, the difficulty of a discrete log attack is maximized. By choosing the pairs in advance, thorough analysis of the pair characteristics is possible. This analysis can promote confidence in the security of the implementations. Precomputation Each party can precompute the D-H public-value. A background process can periodically destroy the old values, generate a new random secret exponent, and recalculate the public-value. This limits the exposure of both the secret exponenent and shared-secret, as past secrets are not kept for possible discovery by a future intrusion, protecting earlier communications. Also, the secret exponent currently in use is less likely to be anticipated, as the element of random timing is introduced. Since these operations involve several time-consuming modular exponentiations, moving them to the "background" substantially speeds up the apparent execution speed of the Photuris protocol. It also reduces CPU loading sufficiently to allow a single public/private key-pair to be used in several closely spaced Photuris executions, when setting up Security Associations with several different hosts over a short period of time. Other precomputation suggestions are described in [w]. Karn & Simpson expires in six months [Page 10] DRAFT Photuris July 1995 2.5. Elliptic Curve Groups The points on an elliptic curve form a group under addition [x]. This group can be used as the basis for the efficient implementation of the Diffie-Hellman operations. In order to uniquely specify the computation, the implementor must know the finite field for representation of the point coordinates, the elliptic curve, and the generator. Note that while the literature uses the term "addition" for the group operation, it is directly analogous to "multiplication" in modular exponentiation groups. Thus, the analogous term for "g**r" is "r*g" (that is, the scalar multiple r of g). The generator is specified as the (x,y) coordinates of an elliptic curve point, and the representation of x and y is given with respect to a finite field. Multiples of the generator are (x,y) pairs. Thus, the Initiator and Responder D-H public-values are to be interpreted as two concatenated bit values in the order (x,y). The lengths of the numbers are implicit in the specification of the field. The field representation is uniquely determined by the irreducible polynomial specified in the group description. The elliptic curve addition formulas are more complicated than straight-forward component-wise addition, and the use of finite fields further complicates the description of the algorithms. A good reference for a succinct description of elliptic curves with finite fields is [y]; a more general treatment can be found in [y]. (same cite ???) Use of a very limited number of fields has similar advantages to those cited for modular exponentiation: reduced overhead, generator selection, and precomputation of the public-values. Karn & Simpson expires in six months [Page 11] DRAFT Photuris July 1995 3. Cookie Exchange 3.1. Cookie_Request +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initiator-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Groups ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 0 Reserved Unused. Zero filled. Initiator-Cookie 16 octets. A randomized value which identifies the exchange. Groups variable. A list of one or more groups supported by the Initiator, in order of preference (see "Group Table" Appendix). Each value is one octet. The end of the list is indicated by the Length of the UDP datagram. The Initiator initializes local state, and sends a Cookie_Request message to the Responder. The Initiator also starts a retransmission timer. If no Cookie_Response is obtained within the time limit, a new Cookie_Request is retransmitted. The Initiator-Cookie value in each successive request SHOULD be different. Karn & Simpson expires in six months [Page 12] DRAFT Photuris July 1995 3.2. Cookie_Response +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Group-Index | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initiator-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Responder-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Responder-Public-Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Responder-Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 1 Group-Index A value selected by the Responder from the list of Groups in the Cookie_Request. Reserved Unused. Zero filled. Initiator-Cookie 16 octets. Copied from the Cookie_Request. Responder-Cookie 16 octets. A randomized value which identifies the exchange. Responder-Public-Value variable precision number. The format is indicated by the Group-Index. Must not be zero or one. Responder-Attributes variable. A list of one or more attributes supported by the Responder, in order of preference. The formats are specified in the "Attribute List" Appendix. The end of the list is indicated by the Length of the UDP datagram. On receipt of a Cookie_Request, the Responder generates a cookie, and returns it in a Cookie_Response message. The Responder-Cookie value Karn & Simpson expires in six months [Page 13] DRAFT Photuris July 1995 in each successive response MAY be different. When too many SPI values are already in use, the Cookie_Request is ignored, and no Error_Message is sent. Note that the Responder creates no state at this time. 3.3. Cookie Generation The exact method by which a Photuris party generates a cookie is implementation dependent. The function chosen must satisfy some basic requirements: 1. The cookie must depend on the specific parties. This prevents an attacker from obtaining a cookie using a real IP address and UDP port, and then using it to swamp the victim with Diffie- Hellman requests from randomly chosen IP addresses or ports. 2. It must not be possible for anyone other than the issuing entity to generate cookies that will be accepted by that entity. This implies that the issuing entity must use local secret information in the generation and subsequent verification of a cookie. It must not be possible to deduce this secret information from any particular cookie. 3. The cookie generation function must be fast to thwart attacks intended to sabotage CPU resources. A recommended method is to calculate a fast cryptographic one-way hash function (such as MD5) over the IP Source and Destination addresses, the UDP Source and Destination ports, and a locally generated secret random value. An incoming cookie can be verified at any time by regenerating it locally from values contained in the incoming IP datagram and the local secret random value. When an old (or invalid) cookie is detected by the Initiator, the message is silently discarded. When an old (or invalid) cookie is detected by the Responder, it is indicated to the Initiator in an Error_Message. The Initiator begins a new Photuris exchange again from the Cookie_Request. Implementation Notes: The Initiator secret random value which affects the cookie SHOULD change for each new Cookie_Request, and is thereafter cached on a Karn & Simpson expires in six months [Page 14] DRAFT Photuris July 1995 Responder basis. This provides improved synchronization and protection against replay attacks. The Responder secret random value is changed whenever the Responder D-H public-value is changed, in order to detect when such changes occur between Cookie_Response and Key_Request. Karn & Simpson expires in six months [Page 15] DRAFT Photuris July 1995 4. Public Value Exchange 4.1. Key_Request +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Group-Index | Initiator-LifeTime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiator-Security-Parameter-Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initiator-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Responder-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initiator-Public-Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiator-Transform | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiator-Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 2 Group-Index Copied from the Cookie_Response. Initiator-LifeTime The number of seconds remaining before the I-SPI expires. Initiator-Security-Parameter-Index (I-SPI) The SPI to be used for sending to the Initiator. Initiator-Cookie 16 octets. Copied from the Cookie_Response. Responder-Cookie 16 octets. Copied from the Cookie_Response. Initiator-Public-Value variable precision number. The format is indicated by the Group-Index. Must not be zero or one. Initiator-Transform variable. Although the field is depicted as 32-bits Karn & Simpson expires in six months [Page 16] DRAFT Photuris July 1995 for convenience, the size may be shorter or longer, as indicated by its Length field. An authentication or encryption transform is selected by the Initiator from the list of Responder-Attributes in the Cookie_Response. One primary transform is indicated, and is used for the Signature Exchange. Additional attributes may be added during the Signature Exchange. Initiator-Attributes variable. A list of one or more attributes supported by the Initiator, in order of preference. The formats are specified in the "Attribute List" Appendix. The end of the list is indicated by the Length of the UDP datagram. On receipt of a Cookie_Response, the Initiator validates the Initiator-Cookie. Invalid messages are silently discarded. When a valid Cookie_Response has been received, a Key_Request is sent. Later Cookie_Responses between the same parties are silently discarded, until a new Cookie_Request is sent. The Initiator also starts a retransmission timer. If no Key_Response is obtained within the time limit, the same Key_Request is retransmitted. Implementation Notes: At this time, the Initiator can begin calculation of the D-H shared-secret. This may take a substantial amount of time. The implementor should ensure that retransmission is not blocked by this calculation. Typically, this is not a problem, as retransmission timeouts exceed calculation time. Karn & Simpson expires in six months [Page 17] DRAFT Photuris July 1995 4.2. Key_Response +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | Responder-LifeTime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Responder-Security-Parameter-Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initiator-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Responder-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Responder-Transform | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key-Transform | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 Responder-LifeTime The number of seconds remaining before the R-SPI expires. Responder-Security-Parameter-Index (R-SPI) The SPI to be used for sending to the Responder. Initiator-Cookie 16 octets. Copied from the Key_Request. Responder-Cookie 16 octets. Copied from the Key_Request. Responder-Transform variable. Although the field is depicted as 32-bits for convenience, the size may be shorter or longer, as indicated by its Length field. An authentication or encryption transform is selected by the Responder from the list of Initiator-Attributes in the Key_Request. One primary transform is indicated, and is used for the Signature Exchange. Additional attributes may be added during the Signature Exchange. Key-Transform variable. Although the field is depicted as 32-bits for convenience, the size may be shorter or longer, Karn & Simpson expires in six months [Page 18] DRAFT Photuris July 1995 as indicated by its Length field. A cryptographic hash function is selected by the Responder from the intersection of the two lists of Attributes, and is used to calculate the session- key. This transform is not necessarily the same as either SPI Transform in use. On receipt of a Key_Request, the Responder validates the Responder- Cookie. Invalid messages are silently discarded. The Responder keeps a copy of the incoming Key_Request message, and its Key_Response message. If a duplicate Key_Request is received, it merely resends the previous Key_Response message, and takes no further action. Implementation Notes: At this time, the Responder begins calculation of the D-H shared- secret. This may take a substantial amount of time. The implementor should ensure that retransmission is not blocked by this calculation. Typically, this is not a problem, as retransmission timeouts exceed calculation time. 4.3. Session-Key Computation Each session-key is the Key-Transform cryptographic hash of the the computed D-H shared-secret, followed by (concatenated with) the SPI, followed by (concatenated with) the SPI owner (receiver) Cookie followed by (concatenated with) the peer (sender) Cookie. Since the SPI is likely to be different in each direction, and the order of the Cookies is different in each direction, the resulting session-key will usually be different in each direction. Both the Initiator and Responder use the resulting SPI session-keys to authenticate or encrypt subsequent messages, including the Signature_Message, Key_Change, and new instantiations of the Photuris exchange between the same nodes. Implementation Notes: Calculation of the D-H shared-secret by the Initiator and Responder is executed in parallel to minimize delay. The D-H public-values and resulting shared-secret SHOULD be cached for the LifeTime of the SPI. When multiple Photuris exchanges Karn & Simpson expires in six months [Page 19] DRAFT Photuris July 1995 occur between the same parties, and the public-values are discovered to be unchanged, the cached shared-secret can be used to rapidly generate new session-keys. Note that the Cookie order is reversed when calculating the Responder session-key. 4.4. Random Number Generation The security of Diffie-Hellman depends critically on the quality of the secret random numbers generated by each party. A poor random number generator at either party will compromise the shared-secret produced by the algorithm. Generating cryptographic quality random numbers on a general purpose computer without hardware assistance is a very tricky problem. In general, this requires using a cryptographic hash function to "distill" the entropy from a large number of semi-random external events, such as the timing of key strokes. An excellent discussion can be found in [4]. 4.5. Secret D-H Components There is surprisingly little guidance in the literature about how large the randomly chosen secret exponent in Diffie-Hellman should be. The size of this exponent dramatically affects the speed of both modular exponentiations involved in Diffie-Hellman. The exponent 0 will generate the public value 1, and exponent 1 will generate the public value g mod p. These exponents do not qualify as secret. In general, small secret exponent values should not be used. Therefore, it is desirable to use the smallest random exponent that is consistent with good security. The most conservative advice received to date [3] is to make the random exponent twice as long as the intended session-key. This ensures that any space/time "meet in the middle" attack on the discrete logarithm problem will be at least as complex as a brute-force search on the resulting session-key space. Implementation Notes: A single modular exponentiation on a 486-66DX2 processor using RSAREF and Borland C under MS-DOS took 20 seconds with a 1024-bit Karn & Simpson expires in six months [Page 20] DRAFT Photuris July 1995 prime modulus and a 1024-bit random exponent. This dropped to about 1 to 1.5 seconds when the random exponent was shortened to 128 bits, with the same 1024-bit modulus. The size of the exponent is entirely implementation dependent, is unknown to the other party, and can be easily changed. Karn & Simpson expires in six months [Page 21] DRAFT Photuris July 1995 5. Signature Exchange 5.1. Signature_Message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initiator-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Responder-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature-Transform | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Signature ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Certificate ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Additional-Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 4 Reserved Unused. Zero filled. Initiator-Cookie 16 octets. Copied from the Key_Request. Responder-Cookie 16 octets. Copied from the Key_Request. Signature-Transform variable. Although the field is depicted as 32-bits for convenience, the size may be shorter or longer, as indicated by its Length field. An authentication transform or certificate attribute is selected from the list of Attributes sent by the peer, and is used to calculate the Signature. This transform is not necessarily the same as any SPI Karn & Simpson expires in six months [Page 22] DRAFT Photuris July 1995 Transform in use. Signature variable precision number. The result of the Signature-Transform. Certificate variable precision number. When the Signature- Transform indicates a certification method, such as X.509, PGP or DNS-SIG, the certificate is included. Additional-Attributes variable. A list of zero or more additional attributes for the Security Association. The formats are specified in the "Attribute List" Appendix. The end of the list is indicated by the Length of the UDP datagram. When the Initiator completes its parallel computation of the D-H shared-secret, and upon receipt of a valid Key_Response, it sends a Signature_Message to the Responder. This message is required to be authenticated or encrypted, using the R-SPI Transform indicated in the Key_Response. The Initiator also starts a retransmission timer. If no Signature_Message response is obtained within the time limit, the same Signature_Message request is retransmitted. When the Responder completes its parallel computation of the D-H shared-secret, and upon receipt of a valid Signature_Message, it sends a Signature_Message to the Initiator. This message is required to be authenticated or encrypted, using the I-SPI Transform indicated in the Key_Request. The Responder keeps a copy of its Signature_Message. If a duplicate Signature_Message is received, it merely resends the previous Signature_Message response, and takes no further action. 5.2. Signature Verification The two parties now verify the signatures received. The indicated Signature-Transform is calculated over the SPI session-key for this direction, followed by (concatenated with) the SPI owner (receiver) Public-Value, followed by (concatenated with) the peer (sender) Public-Value, and optionally followed by (concatenated with) an identifying public-key, certificate, or distinguishing name of the sender. Note that the order of the Public-Values is different in each direction. Karn & Simpson expires in six months [Page 23] DRAFT Photuris July 1995 If they fail, the users are notified, and the Security Association is destroyed. If they succeed, normal operation begins with the authentication and/or encryption of user datagrams. Each party implements local policy that determines what access, if any, is granted to the holder of a particular certification. Implementation Notes: Any authenticated and/or encrypted user datagrams received before the completion of signature verification can be placed on a queue pending completion of this step. If the verification succeeds, the queue is processed as though the datagrams had arrived subsequent to the verification. If the verification fails, the queue is discarded. Early implementations may wish to keep their own trusted public- key databases, such as the Pretty Good Privacy web of trust, and accept only those users found there. Karn & Simpson expires in six months [Page 24] DRAFT Photuris July 1995 6. Other Message Types 6.1. Key_Change +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | Change-LifeTime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security-Parameter-Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initiator-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Responder-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Change-Transform | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Additional-Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 5 Change-LifeTime The number of seconds remaining before the Change- SPI expires. A value of zero indicates deletion of the indicated SPI. Security-Parameter-Index The SPI to be used for incoming communications. This value is required to be different from existing SPI values. The value zero indicates all old SPIs for this IP Destination. Initiator-Cookie 16 octets. Copied from the Key_Request. Responder-Cookie 16 octets. Copied from the Key_Request. Change-Transform variable. Although the field is depicted as 32-bits for convenience, the size may be shorter or longer, as indicated by its Length field. An authentication or encryption transform is selected from the list of Attributes sent by the peer, and is used for the new SPI. This transform is not necessarily the same as any SPI Transform in use. Karn & Simpson expires in six months [Page 25] DRAFT Photuris July 1995 Additional-Attributes variable. A list of zero or more attributes for the Security Association. The formats are specified in the "Attribute List" Appendix. The end of the list is indicated by the Length of the UDP datagram. At any time after the validation of signatures, either party can send a Key_Change. The message has effect in only one direction. When too many SPI values are already in use, an Error_Message response is sent. No retransmission timer is necessary. Success of the keying is indicated by the peer use of the new SPI. Failure will be indicated at expiration of an old SPI, which begins the Photuris exchange again from the Cookie_Request. This message is required to be authenticated or encrypted, using a previous SPI Transform for the peer. The new session-key is calculated using the Key-Transform in the same fashion as described previously. The resulting session-key will be different because the SPI value is different. Since the cached D-H shared-secret remains the same, no new exponentiation is needed. Karn & Simpson expires in six months [Page 26] DRAFT Photuris July 1995 6.2. Error_Message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initiator-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Responder-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 7 Code Indicates the problem: 0 reserved 1 invalid/expired cookie 2 too many concurrent key requests Reserved Unused. Zero filled. Initiator-Cookie 16 octets. Copied from the offending message. Responder-Cookie 16 octets. Copied from the offending message. Issued in response to Photuris state loss or other problems. The message has effect in only one direction. No retransmission timer is necessary. This message is not required to be authenticated or encrypted. Karn & Simpson expires in six months [Page 27] DRAFT Photuris July 1995 A. Group Table The group-index takes the form of a small index into a well-known table. Since only the first few indices will be published, the remaining values may be used by cooperating parties to indicate private groups. (1) Implementation Optional. Elliptic curve: curve: y^2 + xy = x^3 + 0x7338F generator: (0x7B, 0x1C8) irreducible polynomial: u^155 + u^62 + 1 Supplied by Hilarie Orman . (2) Implementation Required. A 1024-bit strong prime (p), expressed in hex: 97f6 4261 cab5 05dd 2828 e13f 1d68 b6d3 dbd0 f313 047f 40e8 56da 58cb 13b8 a1bf 2b78 3a4c 6d59 d5f9 2afc 6cff 3d69 3f78 b23d 4f31 60a9 502e 3efa f7ab 5e1a d5a6 5e55 4313 828d a83b 9ff2 d941 dee9 5689 fada ea09 36ad df19 71fe 635b 20af 4703 6460 3c2d e059 f54b 650a d8fa 0cf7 0121 c747 99d7 5871 32be 9b99 9bb9 b787 e8ab The recommended generator (g) for this prime is 2. This prime was randomly generated by a freely available program written by the author. (5) Implementation Optional. A 1024-bit strong prime (p), expressed in hex: a478 8e21 84b8 d68b fe02 690e 4dbe 485b 17a8 0bc5 f21d 680f 1a84 1313 9734 f7f2 b0db 4e25 3750 018a ad9e 86d4 9b60 04bb bcf0 51f5 2fcb 66d0 c5fc a63f bfe6 3417 3485 bbbf 7642 e9df 9c74 b85b 6855 e942 13b8 c2d8 9162 abef f434 2435 0e96 be41 edd4 2de9 9a69 6163 8c1d ac59 8bc9 0da0 69b5 0c41 4d8e b865 2adc ff4a 270d 567f The recommended generator (g) for this prime is 5. This prime was randomly generated by a freely available program written by the author. Karn & Simpson expires in six months [Page 28] DRAFT Photuris July 1995 (129) Moduli-indices of 129 to 254 are available for private use. Karn & Simpson expires in six months [Page 29] DRAFT Photuris July 1995 B. Attribute List +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type A unique value indicating the authentication, compression, encryption, and signature types available for exchange between the parties. Length The length of the Value field in octets. When the Type is zero, no Length field is present. Value An optional value. The size of the value is indicated by the Length field. When the Length is zero, no Value field is present. Up-to-date values for the Attribute Type are specified in the most recent "Assigned Numbers" [RFC-1700]. Initial values are assigned as follows: (tranforms) K I/R S 0 padding 1 unassigned x x x 2 MD2 3 unassigned x x x 4 MD4 x x x 5* MD5 6 MD6 (reserved) x 7 RSA x 8 PGP certificate x 9 X.509 certificate x 10 DNS-SIG certificate 11 unassigned x 12 RC2 13 unassigned x 14 RC4 15 unassigned x 16 DES-CBC, 0-bit IV x 17* DES-CBC, 32-bit IV x 18* DES-CBC, 64-bit IV 19 unassigned x 20 Triple DES-CBC, 0-bit IV x 21 Triple DES-CBC, 32-bit IV Karn & Simpson expires in six months [Page 30] DRAFT Photuris July 1995 x 22 Triple DES-CBC, 64-bit IV 23 unassigned x x x 24 SHA x 25 DSS x 26 IDEA 27 LZ77 28 Stac LZS 29-254 unassigned x x x 255 Administratively Configured * (implementation required) Each attribute may have value fields which are multiple octets. To facilitate processing efficiency, these fields are aligned on integral (modulo 8) octet boundaries. Padding is accomplished by insertion of 1 to 7 padding octets (Type 0) before the attribute which needs alignment. No padding is used after the final attribute in a list. B.1. MD2 B.2. MD4 B.3. MD5 There are no parameters. The Length is 0, and there is no Value field. B.4. PGP certificate There are no parameters. The Length is 0, and there is no Value field. A Certificate field always follows the Signature field. B.5. DES-CBC, 0-bit IV B.6. DES-CBC, 32-bit IV Karn & Simpson expires in six months [Page 31] DRAFT Photuris July 1995 B.7. DES-CBC, 64-bit IV B.8. Triple DES-CBC, 0-bit IV B.9. Triple DES-CBC, 32-bit IV B.10. Triple DES-CBC, 64-bit IV There are no parameters. The Length is 0, and there is no Value field. B.11. Stac LZS +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | History-Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Check-Mode | +-+-+-+-+-+-+-+-+ Type 28 Length 3 History-Count two octets, most significant octet first. Specifies the maximum number of Compression Histories. The value 0 indicates that the implementation expects the peer to reset the Compression History at the beginning of every packet. The value 1 is used to indicate that only one history is maintained. Other valid values range from 2 to 65535. The peer is not required to send as many histories as the implementation indicates that it can receive. Check-Mode indicates support of LCB, CRC or Sequence checking. 0 None (default) 1 LCB 2 CRC 4 Sequence Number Karn & Simpson expires in six months [Page 32] DRAFT Photuris July 1995 When offered as an Attribute in a Cookie_Response or Key_Request, the History-Count is set to the maximum histories that can be sent, and the Check-Mode is the XOR of the modes supported. When selected as an Additional-Attribute, the History-Count is set to the maximum histories that can be received (less than or equal to the number offered), and the Check-Mode is set to only one of the modes supported. Karn & Simpson expires in six months [Page 33] DRAFT Photuris July 1995 Security Considerations Security issues are the topic of this memo. Acknowledgements This protocol has many elements in common with the Station-To-Station authentication protocol, described in [DOW92]. Hilarie Orman provided text regarding elliptic curves, and extensive review of the protocol details. Paul C van Oorschot suggested signing both the public exponents and the session-key, in order to provide an authentication-only version of signature verification. Randall Atkinson, Cheryl Madson, James Hughes, and Perry Metzger provided useful critiques of earlier versions of this document. Thanks to Bill Simpson for his protocol suggestions, editorial changes and NROFF formatting. All such mistakes are his responsibity. References [1] "Photuris" is the latin name for the firefly. "Firefly" is in turn the name for NSA's (classified) key exchange protocol for the STU-III secure telephone. Informed speculation has it that Firefly is based on very similar design principles. [2] Whitfield Diffie, "Authenticated Key Exchange and Secure Interactive Communication", Northern Telecom, Securicom '90, Paris France, 16 March 1990. [3] Martin Hellman, personal communication. [4] Eastlake, Crocker & Schiller, "Randomness Requirements for Security", work in progress. [5] Bruce Schneier, "Applied Cryptography", ISBN 0-471-59756-2. [6] Kerberos? Karn & Simpson expires in six months [Page 34] DRAFT Photuris July 1995 [A-SA] Randall Atkinson, "Security Architecture for the Internet Protocol", work in progress. [DOW92] Whitfield Diffie, Paul C van Oorshot, Michael J Wiener, "Authentication and Authenticated Key Exchanges", Designs, Codes and Cryptography, v 2 pp 107-125, Kluwer Academic Publishers, 1992. [w] E. Brickell, D. Gordon, K. McCurley, and D. Wilson, "Fast Exponentiation with Precomputation (Extended Abstract)", Advances in Cryptology -- EUROCRYPT '92, Lecture Notes in Computer Science, 658 (1993), Springer-Verlag, 200-207. [x] Alfred J. Menezes, "Elliptic Curve Public Key Cryptosystems", Kluwer Academic Publishers, 1993. [y] Alfred J. Menezes, Minghua Qu, and Scott A. Vanstone, "Standard for RSA, Diffie-Hellman and Related Public Key Cryptography", Working Draft of IEEE P1363 Standard, Oct. 30, 1994. http://www.rsa.com/pub/p1363/draft/ Author's Address Questions about this memo can also be directed to: Phil Karn Qualcomm, Inc. 6455 Lusk Blvd. San Diego, California 92121-2779 karn@qualcomm.com karn@unix.ka9q.ampr.org William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com Karn & Simpson expires in six months [Page 35] DRAFT Photuris July 1995 Table of Contents 1. Introduction .......................................... 1 1.1 Terminology ..................................... 1 1.2 Use of Public-Key Cryptography .................. 2 1.3 Authentication .................................. 2 1.4 Defense against Clogging ........................ 3 1.5 Perfect Forward Secrecy ......................... 4 1.6 Traffic Anonymity ............................... 5 1.7 Security Parameters ............................. 5 1.8 Multicast Support ............................... 6 2. Protocol Description .................................. 7 2.1 UDP ............................................. 8 2.2 Variable Precision Numbers ...................... 8 2.3 Attributes ...................................... 8 2.4 Modular Exponentiation Groups ................... 9 2.5 Elliptic Curve Groups ........................... 11 3. Cookie Exchange ....................................... 12 3.1 Cookie_Request .................................. 12 3.2 Cookie_Response ................................. 13 3.3 Cookie Generation ............................... 14 4. Public Value Exchange ................................. 16 4.1 Key_Request ..................................... 16 4.2 Key_Response .................................... 18 4.3 Session-Key Computation ......................... 19 4.4 Random Number Generation ........................ 20 4.5 Secret D-H Components ........................... 20 5. Signature Exchange .................................... 22 5.1 Signature_Message ............................... 22 5.2 Signature Verification .......................... 23 6. Other Message Types ................................... 25 6.1 Key_Change ...................................... 25 6.2 Error_Message ................................... 27 APPENDICES ................................................... 28 A. Group Table ........................................... 28 B. Attribute List ........................................ 30 B.1 MD2 ............................................. 31 B.2 MD4 ............................................. 31 B.3 MD5 ............................................. 31 Karn & Simpson expires in six months [Page iii] DRAFT Photuris July 1995 B.4 PGP certificate ................................. 31 B.5 DES-CBC, 0-bit IV ............................... 31 B.6 DES-CBC, 32-bit IV .............................. 31 B.7 DES-CBC, 64-bit IV .............................. 32 B.8 Triple DES-CBC, 0-bit IV ........................ 32 B.9 Triple DES-CBC, 32-bit IV ....................... 32 B.10 Triple DES-CBC, 64-bit IV ....................... 32 B.11 Stac LZS ........................................ 32 SECURITY CONSIDERATIONS ...................................... 34 ACKNOWLEDGEMENTS ............................................. 34 REFERENCES ................................................... 34 AUTHOR'S ADDRESS ............................................. 35