RFC 2522
Photuris: Session-Key Management Protocol
Pages: 80
Experimental
Experimental
Part 3 of 3 – Pages 54 to 80
8. Public Value Exchanges
Photuris is based in principle on public-key cryptography, specifically Diffie-Hellman key exchange. Exchange of public D-H Exchange-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. This document assumes familiarity with the Diffie-Hellman public-key algorithm. A good description can be found in [Schneier95].8.1. Modular Exponentiation Groups
The original Diffie-Hellman technique [DH76] 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 these public-values are exchanged between parties, the parties can calculate a shared-secret value between themselves: (g**xy) mod p. The generator (g) and modulus (p) are established by the Scheme- Choice (see the "Basic Exchange-Schemes" for details). They are offered in the Cookie_Response, and one pair is chosen in the Value_Request. The private exponents (x) and (y) are kept secret by the parties. Only the public-value result of the modular exponentiation with (x) or (y) is sent as the Initiator and Responder Exchange-Value. These public-values are represented in single Variable Precision Integers. The Size of these Exchange-Values will match the Size of the modulus (p).8.2. Moduli Selection
Each implementation proposes one or more moduli in its Offered- Schemes. Every implementation MUST support up to 1024-bit moduli. For any particular Photuris node, these moduli need not change for significant periods of time; likely days or weeks. A background process can periodically generate new moduli.
For 512-bit moduli, current estimates would provide 64
(pessimistic) bit-equivalents of cryptographic strength.
For 1024-bit moduli, current estimates would range from 80
(pessimistic) through 98 (optimistic) bit-equivalents of
cryptographic strength.
These estimates are used when choosing moduli that are appropriate
for the desired Security Parameter attributes.
8.2.1. Bootstrap Moduli
Each implementation is likely to use a fixed modulus during its
bootstrap, until it can generate another modulus in the background.
As the bootstrap modulus will be widely distributed, and reused
whenever the machine reinitializes, it SHOULD be a "safe" prime (p =
2q+1) to provide the greatest long-term protection.
Implementors are encouraged to generate their own bootstrap moduli,
and to change bootstrap moduli in successive implementation releases.
8.2.2. Learning Moduli
As Photuris exchanges are initiated, new moduli will be learned from
the Responder Offered-Schemes. The Initiator MAY cache these moduli
for its own use.
Before offering any learned modulus, the implementation MUST perform
at least one iteration of probable primality verification. In this
fashion, many processors will perform verification in parallel as
moduli are passed around.
When primality verification failures are found, the failed moduli
SHOULD be retained for some (implementation dependent) period of
time, to avoid re-learning and re-testing after subsequent exchanges.
8.3. Generator Selection
The generator (g) should be chosen such that the private-secret
exponents will generate all possible public-values, evenly
distributed throughout the range of the modulus (p), without cycling
through a smaller subset. Such a generator is called a "primitive
root" (which is trivial to find when p is "safe").
Only one generator (2) is required to be supported.
Implementation Notes:
One useful technique is to select the generator, and then limit
the modulus selection sieve to primes with that generator:
2 when p (mod 24) = 11.
3 when p (mod 12) = 5.
5 when p (mod 10) = 3 or 7.
The required generator (2) improves efficiency in multiplication
performance. It is usable even when it is not a primitive root,
as it still covers half of the space of possible residues.
8.4. Exponent Selection
Each implementation generates a separate random private-secret
exponent for each different modulus. Then, a D-H Exchange-Value is
calculated for the given modulus, generator, and exponent.
This specification recommends that the exponent length be at least
twice the desired cryptographic strength of the longest session-key
needed by the strongest offered-attribute.
Based on the estimates in "Moduli Selection" (above):
For 512-bit moduli, exponent lengths of 128 bits (or more) are
recommended.
For 1024-bit moduli, exponent lengths of 160 to 256 bits (or more)
are recommended.
Although the same exponent and Exchange-Value may be used with
several parties whenever the same modulus and generator are used, the
exponent SHOULD be changed at random intervals. A background process
can periodically destroy the old values, generate a new random
private-secret exponent, and recalculate the Exchange-Value.
Implementation Notes:
The size of the exponent is entirely implementation dependent, is
unknown to the other party, and can be easily changed.
Since these operations involve several time-consuming modular
exponentiations, moving them to the "background" substantially
improves 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 creating Security Associations with
several different nodes over a short period of time.
Other pre-computation suggestions are described in [BGMW93, LL94,
Rooij94].
8.5. Defective Exchange Values
Some exponents do not qualify as secret. The exponent 0 will
generate the Exchange-Value 1, and the exponent 1 will generate the
Exchange-Value g. Small exponents will be easily visible and SHOULD
be avoided where:
g**x < p.
Depending on the structure of the moduli, certain exponents can be
used for sub-group confinement attacks. For "safe" primes (p =
2q+1), these exponents are p-1 and (p-1)/2, which will generate the
Exchange-Values 1 and p-1 respectively.
When an implementation chooses a random exponent, the resulting
Exchange-Value is examined. If the Exchange-Value is represented in
less than half the number of significant bits in the modulus, then a
new random exponent MUST be chosen.
For 512-bit moduli, Exchange-Values of 2**256 or greater are
required.
For 1024-bit moduli, Exchange-Values of 2**512 or greater are
required.
In addition, if the resulting Exchange-Value is p-1, then a new
random exponent MUST be chosen.
Upon receipt of an Exchange-Value that fails to meet the
requirements, the Value Exchange message is silently discarded.
Implementation Notes:
Avoidance of small exponents can be assured by setting at least
one bit in the most significant half of the exponent.
9. Basic Exchange-Schemes
Initial values are assigned as follows: (0) Reserved. (1) Reserved. (2) Implementation Required. Any modulus (p) with a recommended generator (g) of 2. When the Exchange-Scheme Size is non-zero, the modulus is contained in the Exchange-Scheme Value field in the list of Offered-Schemes. An Exchange-Scheme Size of zero is invalid. Key-Generation-Function "MD5 Hash" Privacy-Method "Simple Masking" Validity-Method "MD5-IPMAC Check" This combination of features requires a modulus with at least 64-bits of cryptographic strength. (3) Exchange-Schemes 3 to 255 are intended for future well-known published schemes. (256) Exchange-Schemes 256 to 32767 are intended for vendor-specific unpublished schemes. Implementors wishing a number MUST request the number from the authors. (32768) Exchange-Schemes 32768 to 65535 are available for cooperating parties to indicate private schemes, regardless of vendor implementation. These numbers are not reserved, and are subject to duplication. Other criteria, such as the IP Source and Destination of the Cookie_Request, are used to differentiate the particular Exchange-Schemes available.
10. Basic Key-Generation-Function
10.1. MD5 Hash
MD5 [RFC-1321] is used as a pseudo-random-function for generating the key(s). The key(s) begin with the most significant bits of the hash. MD5 is iterated as needed to generate the requisite length of key material. When an individual key does not use all 128-bits of the last hash, any remaining unused (least significant) bits of the last hash are discarded. When combined with other uses of key generation for the same purpose, the next key will begin with a new hash iteration.11. Basic Privacy-Method
11.1. Simple Masking
As described in "Privacy-Key Computation", sufficient privacy-key material is generated to match the message length, beginning with the next field after the SPI, and including the Padding. The message is masked by XOR with the privacy-key.12. Basic Validity-Method
12.1. MD5-IPMAC Check
As described in "Validity Verification", the Verification field value is the MD5 [RFC-1321] hash over the concatenation of MD5( key, keyfill, data, datafill, key, md5fill ) where the key is the computed verification-key. The keyfill and datafill use the same pad-with-length technique defined for md5fill. This padding and length is implicit, and does not appear in the datagram. The resulting Verification field is a 128-bit Variable Precision Integer (18 bytes including Size). When used in calculations, the Verification data includes both the Size and Value fields.
13. Basic Attributes
Implementors wishing a number MUST request the number from the authors. Initial values are assigned as follows: Use Type - 0* padding - 1* AH-Attributes - 2+ ESP-Attributes AEI 5* MD5-IPMAC AEIX 255+ Organizational A AH Attribute-Choice E ESP Attribute-Choice I Identity-Choice X dependent on list location + feature must be recognized even when not supported * feature must be supported (mandatory) Other attributes are specified in companion documents.13.1. Padding
+-+-+-+-+-+-+-+-+ | Attribute | +-+-+-+-+-+-+-+-+ Attribute 0 Each attribute may have value fields that are multiple bytes. To facilitate processing efficiency, these fields are aligned on integral modulo 8 byte (64-bit) boundaries. Padding is accomplished by insertion of 1 to 7 Attribute 0 padding bytes before the attribute that needs alignment. No padding is used after the final attribute in a list.
13.2. AH-Attributes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute 1 Length 0 When a list of Attributes is specified, this Attribute begins the section of the list which applies to the Authentication Header (AH).13.3. ESP-Attributes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute | Length | PayloadType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute 2 Length 1 PayloadType 1 byte. Indicates the contents of the ESP Transform Data field, using the IP Next Header (Protocol) value. Up-to-date values of the IP Next Header (Protocol) are specified in the most recent "Assigned Numbers" [RFC-1700]. For example, when encrypting an entire IP datagram, this field will contain the value 4, indicating IP- in-IP encapsulation. When a list of Attributes is specified, this Attribute begins the section of the list which applies to the Encapsulating Security Payload (ESP). When listed as an Offered-Attribute, the PayloadType is set to 255. When selected as an Attribute-Choice, the PayloadType is set to the actual value to be used.
13.4. MD5-IPMAC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute 5 Length 013.4.1. Symmetric Identification
When selected as an Identity-Choice, the immediately following Identification field contains an unstructured Variable Precision Integer. Valid Identifications and symmetric secret-keys are preconfigured by the parties. There is no required format or content for the Identification value. The value may be a number or string of any kind. See "Use of Identification and Secrets" for details. The symmetric secret-key (as specified) is selected based on the contents of the Identification field. All implementations MUST support at least 62 bytes. The selected symmetric secret-key SHOULD provide at least 64-bits of cryptographic strength. As described in "Identity Verification", the Verification field value is the MD5 [RFC-1321] hash over the concatenation of: MD5( key, keyfill, data, datafill, key, md5fill ) where the key is the computed verification-key. The keyfill and datafill use the same pad-with-length technique defined for md5fill. This padding and length is implicit, and does not appear in the datagram. The resulting Verification field is a 128-bit Variable Precision Integer (18 bytes including Size). When used in calculations, the Verification data includes both the Size and Value fields. For both "Identity Verification" and "Validity Verification", the verification-key is the MD5 [RFC-1321] hash of the following concatenated values:
+ the symmetric secret-key,
+ the computed shared-secret.
For "Session-Key Computation", the symmetric secret-key is used
directly as the generation-key.
Regardless of the internal representation of the symmetric secret-
key, 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 symmetric secret-key does not include a Size field.
13.4.2. Authentication
May be selected as an AH or ESP Attribute-Choice, pursuant to [RFC-
1828] et sequitur. The selected Exchange-Scheme SHOULD provide at
least 64-bits of cryptographic strength.
As described in "Session-Key Computation", the most significant 384-
bits (48 bytes) of the Key-Generation-Function iterations are used
for the key.
Profile:
When negotiated with Photuris, the transform differs slightly from
[RFC-1828].
The form of the authenticated message is:
MD5( key, keyfill, datagram, datafill, key, md5fill )
where the key is the SPI session-key.
The additional datafill protects against the (impractical) attack
described in [PO96]. The keyfill and datafill use the same pad-
with-length technique defined for md5fill. This padding and
length is implicit, and does not appear in the datagram.
13.5. Organizational
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute | Length | OUI +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Kind | Value(s) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute 255 Length >= 4 When the Length is four, no Value(s) field is present. OUI 3 bytes. The vendor's Organizationally Unique Identifier, assigned by IEEE 802 or IANA (see [RFC- 1700] for contact details). The bits within the byte are in canonical order, and the most significant byte is transmitted first. Kind 1 byte. Indicates a sub-type for the OUI. There is no standardization for this field. Each OUI implements its own values. Value(s) 0 or more bytes. The details are implementation specific. Some implementors might not need nor want to publish their proprietary algorithms and attributes. This OUI mechanism is available to specify these without encumbering the authors with proprietary number requests.
A. Automaton
An example automaton is provided to illustrate the operation of the protocol. It is incomplete and non-deterministic; many of the Good/Bad semantic decisions are policy-based or too difficult to represent in tabular form. Where conflicts appear between this example and the text, the text takes precedence. The finite-state automaton is defined by events, actions and state transitions. Events include reception of external commands such as expiration of a timer, and reception of datagrams from a peer. Actions include the starting of timers and transmission of datagrams to the peer. Events DU13 = Communication Administratively Prohibited SF0 = Bad SPI SF4 = Need Authentication SF5 = Need Authorization WC = Want Confidentiality RCQ+ = Receive Cookie_Request (Good) RCQ- = Receive Cookie_Request (Bad) RCR+ = Receive Cookie_Response (Good) RCR- = Receive Cookie_Response (Bad) RVQ+ = Receive Value_Request (Good) RVQ- = Receive Value_Request (Bad) RVR+ = Receive Value_Response (Good) RVR- = Receive Value_Response (Bad) RIQ+ = Receive Identity_Request (Good) RIQ- = Receive Identity_Request (Bad) RIR+ = Receive Identity_Response (Good) RIR- = Receive Identity_Response (Bad) RUN+ = Receive SPI_Needed (Good) RUN- = Receive SPI_Needed (Bad) RUM+ = Receive SPI_Update (Good) RUM- = Receive SPI_Update (Bad) RBC = Receive Bad Cookie RRL = Receive Resource Limit RVF = Receive Verification Failure RMR = Receive Message Reject TO+ = Timeout with counter > 0
TO- = Timeout with counter expired UTO = Update TimeOut XTO = Exchange TimeOut Actions scq = Send Cookie_Request scr = Send Cookie_Response svq = Send Value_Request svr = Send Value_Response siq = Send Identity_Request sir = Send Identity_Response sum = Send SPI_Update se* = Send error message (see text) sbc = Send Bad Cookie srl = Send Resource Limit svf = Send Verification Failure brto = Backoff Retransmission TimeOut buto = Backoff Update TimeOut rto = Set Retransmission TimeOut uto = Set Update TimeOut xto = Set Exchange TimeOut log = log operator messageA.1. State Transition Table
States are indicated horizontally, and events are read vertically. State transitions and actions are represented in the form action/new-state. Multiple actions are separated by commas, and may continue on succeeding lines as space requires; multiple actions may be implemented in any convenient order. The state may be followed by a letter, which indicates an explanatory footnote. The dash ('-') indicates an illegal transition.
Initiator
| 0 1 2 3 4
| Initial Cookie CookieBad Value ValueBad
------+--------------------------------------------------
DU13 |rto,scq/1 rto,scq/1 rto,scq/1 3 4
SF0 |rto,scq/1 1 2 3 4
SF4 |rto,scq/1 1 2 3 4
SF5 |rto,scq/1 1 2 3 4
WC |rto,scq/1 1 2 3 4
|
RCR+ | - rto,svq/3 rto,svq/3 3 4
RCR- | 0 1 2 3 4
RVR+ | - - - rto,siq/5 rto,siq/5
RVR- | 0 1 2 3 4
RIR+ | - - - - -
RIR- | 0 1 2 3 4
|
RUN+ | - - - - -
RUN- | sbc/0 sbc/1 sbc/2 sbc/3 sbc/4
RUM+ | - - - - -
RUM- | sbc/0 sbc/1 sbc/2 sbc/3 sbc/4
|
RBC | - - - 4 4
RRL | - brto/2 brto/2 brto/4 brto/4
RVF | - - - - -
RMR | - - - - -
|
TO+ | - scq/1 scq/2 svq/3 svq/4
TO- | - 0 scq/1 0 scq/1
UTO | - - - - -
XTO | - 0 0 0 0
Initiator
| 5 6 8
|Identity IdentityBad Update
------+-----------------------------
DU13 | 5 6 8
SF0 | 5 6 rto,scq/1
SF4 | 5 6 rto,scq/1
SF5 | 5 6 rto,scq/1
WC | 5 6 sun/8
|
RCR+ | 5 6 8
RCR- | 5 6 8
RVR+ | 5 6 8
RVR- | 5 6 8
RIR+ | uto/8 uto/8 8
RIR- | svf/5 svf/6 8
|
RUN+ | - - sum/8
RUN- | sbc/5 sbc/6 se*/8
RUM+ | - - 8
RUM- | sbc/5 sbc/6 se*/8
|
RBC | 6 6 rto,scq/1
RRL | 5 6 buto/8
RVF | log/5 log/6 log/8
RMR | log/5 log/6 log/8
|
TO+ | sim/5 sim/6 -
TO- | 0 scq/1 -
UTO | - - sum/8
XTO | 0 0 0
Responder
| 0 7 8
| Initial Ready Update
------+-----------------------------
WC | - 7 sun/8
|
RCQ+ | scr/0 scr/7 scr/8
RCQ- | srl/0 srl/7 srl/8
RVQ+ |xto,svr/7 svr/7 svr/8
RVQ- | sbc/0 sbc/7 sbc/8
RIQ+ | - uto,sir/8 sir/8
RIQ- | sbc/0 se*/7 se*/8
|
RUN+ | - - sum/8
RUN- | sbc/0 sbc/7 se*/8
RUM+ | - - 8
RUM- | sbc/0 sbc/7 se*/8
|
RBC | - 7 rto,scq/1
RRL | - - buto/8
RVF | - - log/8
RMR | - - log/8
|
UTO | - - sum/8
XTO | - 0 0
A.2. States
Following is a more detailed description of each automaton state.
The "Bad" version of a state is to indicate that the Bad_Cookie or
Resource_Limit message has been received.
A.2.1. Initial
The Initial state is fictional, in that there is no state between the
parties.
A.2.2. Cookie
In the Cookie state, the Initiator has sent a Cookie_Request, and is waiting for a Cookie_Response. Both the Restart and Exchange timers are running. Note that the Responder has no Cookie state.A.2.3. Value
In the Value state, the Initiator has sent its Exchange-Value, and is waiting for an Identity_Message. Both the Restart and Exchange timers are running.A.2.4. Identity
In the Identity state, the Initiator has sent an Identity_Request, and is waiting for an Identity_Response in reply. Both the Restart and Exchange timers are running.A.2.5. Ready
In the Ready state, the Responder has sent its Exchange-Value, and is waiting for an Identity_Message. The Exchange timer is running.A.2.6. Update
In the Update state, each party has concluded the Photuris exchange, and is unilaterally updating expiring SPIs until the Exchange LifeTime expires. Both the Update and Exchange timers are running.
B. Use of Identification and Secrets
Implementation of the base protocol requires support for operator configuration of participant identities and associated symmetric secret-keys. The form of the Identification and Secret fields is not constrained to be a readable string. In addition to a simpler quoted string configuration, an implementation MUST allow configuration of an arbitrary stream of bytes.B.1. Identification
Typically, the Identification is a user name, a site name, a Fully Qualified Domain Name, or an email address which contains a user name and a domain name. Examples include: user node.site. user@node.site. rcmd@node.site. "Mundane Name" <user@node.site> There is no requirement that the domain name match any of the particular IP addresses in use by the parties.B.2. Group Identity With Group Secret
A simple configuration approach could use a single Identity and Secret, distributed to all the participants in the trusted group. This might be appropriate between routers under a single administration comprising a Virtual Private Network over the Internet. Nota Bene: The passwords used in these examples do not meet the "MD5-IPMAC Symmetric Identification" recommendation for at least 64-bits of cryptographic strength. The administrator configures each router with the same username and password: identity local "Tiny VPN 1995 November" "abracadabra" identity remote "Tiny VPN 1995 November" "abracadabra" When the Initiator sends its Identity_Request, the SPI Owner
Identification field is "Tiny VPN 1995 November" and the SPI Owner secret-key is "abracadabra". When the Responder sends its Identity_Response, the SPI Owner Identification field is "Tiny VPN 1995 November" and the SPI Owner secret-key is "abracadabra". The SPI User Identification is "Tiny VPN 1995 November" (taken from the request), and the SPI User secret-key is "abracadabra". Note that even in the face of implementations with very poor random number generation yielding the same random numbers for both parties at every step, and with this completely identical configuration, the addition of the SPI User Verification field in the response calculation is highly likely to produce a different Verification value (see "Identity Verification"). In turn, the different Verification values affect the calculation of SPI session-keys that are highly likely to be different in each direction (see "Session-Key Computation").B.3. Multiple Identities With Group Secrets
A more robust configuration approach could use a separate Identity and Secret for each party, distributed to the participants in the trusted group. This might be appropriate for authenticated firewall traversal. An administrator has one or more networks, and a number of mobile users. It is desirable to restrict access to authorized external users. The example boundary router is 10.0.0.1. The administrator gives each user a different username and password, together with a group username and password for the router. The administrator configures (in part): identity local "199511@router.site" "FalDaRah" identity remote "Happy_Wanderer@router.site" "FalDaRee" Each mobile user adds commands to tunnel and authenticate. route addprivate 10.0.0.0/8 tunnel 10.0.0.1 secure 10.0.0.1 authenticate-only identity local "Happy_Wanderer@router.site" "FalDaRee" identity remote "199511@router.site" "FalDaRah" identity remote "199512@router.site" "FalDaHaHaHaHaHaHa" When the mobile Initiator sends its Identity_Request, the SPI Owner
Identification field is "Happy_Wanderer@router.site" and the SPI Owner secret-key is "FalDaRee". When the firewall Responder sends its Identity_Response, the SPI Owner Identification field is "199511@router.site" and the SPI Owner secret-key is "FalDaRah". The SPI User Identification field is "Happy_Wanderer@router.site" (taken from the request), and the SPI User secret-key is "FalDaRee". In this example, the mobile user is already prepared for a monthly password changeover, where the router might identify itself as "199512@router.site".B.4. Multiple Identities With Multiple Secrets
Greater security might be achieved through configuration of a pair of secrets between each party. As before, one secret is used for initial contact to any member of the group, but another secret is used between specific parties. Compromise of one secret or pair of secrets does not affect any other member of the group. This might be appropriate between the routers forming a boundary between cooperating Virtual Private Networks that establish local policy for each VPN member access. One administrator configures: identity local "Apple" "all for one" identity local "Apple-Baker" "Apple to Baker" "Baker" identity remote "Baker" "one for all" identity remote "Baker-Apple" "Baker to Apple" Another configures: identity local "Baker" "one for all" identity local "Baker-Apple" "Baker to Apple" "Apple" identity remote "Apple" "all for one" identity remote "Apple-Baker" "Apple to Baker" When the Initiator sends its Identity_Request, the SPI Owner Identification field is "Apple" and the SPI Owner secret-key is "all for one". When the Responder sends its Identity_Response, finding that the special pairing exists for "Apple" (in this example, indicated by a third field), the SPI Owner Identification field is "Baker-Apple" and the SPI Owner secret-key is "Baker to Apple". The SPI User Identification is "Apple" (taken from the request), and the SPI User
secret-key is "all for one".Operational Considerations
The specification provides only a few configurable parameters, with defaults that should satisfy most situations. Retransmissions Default: 3. Initial Retransmission TimeOut (IRTO) Default: 5 seconds. Exchange TimeOut (ETO) Default: 30 seconds. Minimum: Retransmissions * IRTO. Exchange LifeTime (ELT) Default: 30 minutes. Minimum: 2 * ETO. SPI LifeTime (SPILT) Default: 5 minutes. Minimum: 3 * ETO. Each party configures a list of known identities and symmetric secret-keys. 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
Photuris was based on currently available tools, by experienced network protocol designers with an interest in cryptography, rather than by cryptographers with an interest in network protocols. This specification is intended to be readily implementable without requiring an extensive background in cryptology. Therefore, only minimal background cryptologic discussion and rationale is included in this document. Although some review has been provided by the general cryptologic community, it is anticipated that design decisions and tradeoffs will be thoroughly analysed in subsequent dissertations and debated for many years to come. Cryptologic details are reserved for separate documents that may be more readily and timely updated with new analysis.
History
The initial specification of Photuris, now called version 1 (December 1994 to March 1995), was based on a short list of design requirements, and simple experimental code by Phil Karn. Only one modular exponentiation form was used, with a single byte index of pre-specified group parameters. The transform attributes were selected during the public value exchange. Party privacy was protected in the identification signature exchange with standard ESP transforms. Upon submission for review by the IP Security Working Group, a large number of features were demanded. A mere 254 future group choices were not deemed enough; it was expanded to two bytes (and renamed schemes), and was expanded again to carry variable parameters. The transform attributes were made variable length to accomodate optional parameters. Every other possible parameter was made negotiable. Some participants were unable to switch modes on the UDP sockets to use standard ESP transforms for only some messages, and party privacy was integrated into the protocol. The message headers were reorganized, and selection of transform attributes was delayed until the identification exchange. An additional update message phase was added. Version 2 (July 1995 to December 1995) specification stability was achieved in November 1995 by moving most parameters into separate documents for later discussion, and leaving only a few mandatory features in the base specification. Within a month, multiple interoperable implementations were produced. Unfortunately, in a fit of demagoguery, the IP Security Working Group decided in a straw poll to remove party privacy protection, and the Working Group chair terminated the meeting without allowing further discussion. Because the identification exchange messages required privacy to function correctly, the messages were reorganized again. Party privacy and other optional schemes were split into a separate document. The implementors established a separate discussion group. Version 3 (April 1996 to June 1997) enjoyed a long period of specification stability and multiple implementations on half a dozen platforms. Meanwhile, the IP Security Working Group has developed a competing specification with large numbers of negotiable parameters. Also, the PPP Extensions Working Group has deployed link security transforms. Version 4 (July 1997 onward) attempts to maintain a semblance of interface compatibility with these other efforts. Minor changes are
specified in transform padding format and key generation. More than one value is permitted per scheme, giving greater latitude in choice for future extensions. The opportunity is taken to return party privacy to the base document, and make small semantic changes in automated updates and error recovery. All ESP transform attributes are moved to separate documents, to (hopefully) avoid future incompatible changes to the base document.Acknowledgements
Thou shalt make no law restricting the size of integers that may be multiplied together, nor the number of times that an integer may be multiplied by itself, nor the modulus by which an integer may be reduced. [Prime Commandment] Phil Karn was principally responsible for the design of the protocol phases, particularly the "cookie" anti-clogging defense, developed the initial testing implementation, and provided much of the design rationale text (now removed to a separate document). William Simpson was responsible for the packet formats and attributes, additional message types, editing and formatting. All such mistakes are his responsibility. This protocol was later discovered to have many elements in common with the Station-To-Station authentication protocol [DOW92]. Angelos Keromytis developed the first completely independent implementation (circa October 1995). Also, he suggested the cookie exchange rate limitation counter. Paul C van Oorschot suggested signing both the public exponents and the shared-secret, to provide an authentication-only version of identity verification. Also, he provided text regarding moduli, generator, and exponent selection (now removed to a separate document). Hilarie Orman suggested adding secret "nonces" to session-key generation for asymmetric public/private-key identity methods (now removed to a separate document), and provided extensive review of the protocol details. Bart Preneel and Paul C van Oorschot in [PO96] recommended padding between the data and trailing key when hashing for authentication. Niels Provos developed another independent implementation (circa May 1997), ported to AIX, Linux, OpenBSD, and Solaris. Also, he made
suggestions regarding automated update, and listing multiple moduli per scheme. Bill Sommerfeld suggested including the authentication symmetric secret-keys in the session-key generation, and using the Cookie values on successive exchanges to provide bi-directional user- oriented keying (now removed to a separate document). Oliver Spatscheck developed the second independent implementation (circa December 1995) for the Xkernel. International interoperability testing between early implementors provided the impetus for many of the implementation notes herein, and numerous refinements in the semantics of the protocol messages. Randall Atkinson, Steven Bellovin, Wataru Hamada, James Hughes, Brian LaMacchia, Cheryl Madson, Lewis McCarthy, Perry Metzger, Bob Quinn, Ron Rivest, Rich Schroeppel, and Norman Shulman provided useful critiques of earlier versions of this document. Special thanks to the Center for Information Technology Integration (CITI) for providing computing resources.References
[BGMW93] 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. Also U.S. Patent #5,299,262, E.F. Brickell, D.M. Gordon, K.S. McCurley, "Method for exponentiating in cryptographic systems", 29 Mar 1994. [DH76] Diffie, W., and Hellman, H.E., "New Directions in Cryptography", IEEE Transactions on Information Theory, v IT-22 n 6 pp 644-654, November 1976. [DOW92] Whitfield Diffie, Paul C van Oorshot, and Michael J Wiener, "Authentication and Authenticated Key Exchanges", Designs, Codes and Cryptography, v 2 pp 107-125, Kluwer Academic Publishers, 1992. [Firefly] "Photuris" is the latin name for the firefly. "Firefly" is in turn the name for the USA National Security Administration's (classified) key exchange protocol for the STU-III secure telephone. Informed speculation has
it that Firefly is based on very similar design
principles.
[LL94] Lim, C.H., Lee, P.J., "More flexible exponentiation with
precomputation", Advances in Cryptology -- Crypto '94,
Lecture Notes in Computer Science 839 (1994), Springer-
Verlag, pages 95-107.
[Prime Commandment]
A derivation of an apocryphal quote from the usenet list
sci.crypt.
[PO96] Bart Preneel, and Paul C van Oorshot, "On the security of
two MAC algorithms", Advances in Cryptology -- Eurocrypt
'96, Lecture Notes in Computer Science 1070 (May 1996),
Springer-Verlag, pages 19-32.
[RFC-768] Postel, J., "User Datagram Protocol", STD 6,
USC/Information Sciences Institute, August 1980.
[RFC-791] Postel, J., "Internet Protocol", STD 5, USC/Information
Sciences Institute, September 1981.
[RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", MIT
Laboratory for Computer Science, April 1992.
[RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2,
USC/Information Sciences Institute, October 1994.
[RFC-1812] Baker, F., Editor, "Requirements for IP Version 4
Routers", Cisco Systems, June 1995.
[RFC-1828] Metzger, P., Simpson, W., "IP Authentication using Keyed
MD5", July 1995.
[RFC-1829] Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC
Transform", July 1995.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, Harvard University, March
1997.
[RFC-2521] Karn, P., and Simpson, W., "ICMP Security Failures
Messages", March 1999.
[Rooij94] P. de Rooij, "Efficient exponentiation using
precomputation and vector addition chains", Advances in
Cryptology -- Eurocrypt '94, Lecture Notes in Computer
Science, Springer-Verlag, pages 403-415.
[Schneier95]
Schneier, B., "Applied Cryptography Second Edition", John
Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7.
Contacts
Comments about this document should be discussed on the
photuris@adk.gr mailing list.
Questions about this document 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 (preferred)
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) The Internet Society (1999). Copyright (C) Philip Karn
and William Allen Simpson (1994-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, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards (in which case the procedures for
copyrights defined in the Internet Standards process must be
followed), or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE 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.