Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 2522


Photuris: Session-Key Management Protocol

Part 3 of 3, p. 54 to 80
Prev RFC Part


prevText      Top      Up      ToC       Page 54 
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

   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      Up      ToC       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      Up      ToC       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

      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      Up      ToC       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,

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

      For 1024-bit moduli, Exchange-Values of 2**512 or greater are

   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      Up      ToC       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.

         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      Up      ToC       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

   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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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.


      When negotiated with Photuris, the transform differs slightly from

      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      Up      ToC       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

   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

   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      Up      ToC       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.


   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      Up      ToC       Page 66 
   TO-  = Timeout with counter expired
   UTO  = Update TimeOut
   XTO  = Exchange TimeOut


   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      Up      ToC       Page 67 

         |    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      Up      ToC       Page 68 

         |    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      Up      ToC       Page 69 

         |    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

Top      Up      ToC       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      Up      ToC       Page 71 
B.  Use of Identification and Secrets

   Implementation of the base protocol requires support for operator
   configuration of participant identities and associated symmetric

   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:

      "Mundane Name" <>

   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

   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

      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      Up      ToC       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

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

   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

   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 "" "FalDaRah"
      identity remote "" "FalDaRee"

   Each mobile user adds commands to tunnel and authenticate.

      route addprivate tunnel
      secure authenticate-only
      identity local "" "FalDaRee"
      identity remote "" "FalDaRah"
      identity remote "" "FalDaHaHaHaHaHaHa"

   When the mobile Initiator sends its Identity_Request, the SPI Owner

Top      Up      ToC       Page 73 
   Identification field is "" and the SPI
   Owner secret-key is "FalDaRee".

   When the firewall Responder sends its Identity_Response, the SPI
   Owner Identification field is "" and the SPI Owner
   secret-key is "FalDaRah".  The SPI User Identification field is
   "" (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

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      Up      ToC       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.

      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

   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      Up      ToC       Page 75 

   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

   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

   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

   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      Up      ToC       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.


      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

   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      Up      ToC       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.


   [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      Up      ToC       Page 78 
               it that Firefly is based on very similar design

   [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

   [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

   [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      Up      ToC       Page 79 
               Science, Springer-Verlag, pages 403-415.

               Schneier, B., "Applied Cryptography Second Edition", John
               Wiley & Sons, New York, NY, 1995.  ISBN 0-471-12845-7.


   Comments about this document should be discussed on the mailing list.

   Questions about this document can also be directed to:

      Phil Karn
      Qualcomm, Inc.
      6455 Lusk Blvd.
      San Diego, California  92121-2779


      William Allen Simpson
      Computer Systems Consulting Services
      1384 Fontaine
      Madison Heights, Michigan  48071


Top      Up      ToC       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

   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