Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2522

Photuris: Session-Key Management Protocol

Pages: 80
Experimental
Part 3 of 3 – Pages 54 to 80
First   Prev   None

Top   ToC   RFC2522 - Page 54   prevText

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.
Top   ToC   RFC2522 - Page 55
      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.
Top   ToC   RFC2522 - Page 56
   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
Top   ToC   RFC2522 - Page 57
      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.
Top   ToC   RFC2522 - Page 58

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.
Top   ToC   RFC2522 - Page 59

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.
Top   ToC   RFC2522 - Page 60

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.
Top   ToC   RFC2522 - Page 61

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.
Top   ToC   RFC2522 - Page 62

13.4. MD5-IPMAC

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute 5 Length 0

13.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:
Top   ToC   RFC2522 - Page 63
    + 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.
Top   ToC   RFC2522 - Page 64

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.
Top   ToC   RFC2522 - Page 65

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
Top   ToC   RFC2522 - Page 66
   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 message


A.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.
Top   ToC   RFC2522 - Page 67
   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
Top   ToC   RFC2522 - Page 68
   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
Top   ToC   RFC2522 - Page 69
   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.
Top   ToC   RFC2522 - Page 70

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.
Top   ToC   RFC2522 - Page 71

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
Top   ToC   RFC2522 - Page 72
   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
Top   ToC   RFC2522 - Page 73
   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
Top   ToC   RFC2522 - Page 74
   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.
Top   ToC   RFC2522 - Page 75

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
Top   ToC   RFC2522 - Page 76
   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
Top   ToC   RFC2522 - Page 77
   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
Top   ToC   RFC2522 - Page 78
               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
Top   ToC   RFC2522 - Page 79
               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)
Top   ToC   RFC2522 - Page 80
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.