# Photuris: Session-Key Management Protocol

Pages: 80
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.
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"
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

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

+-+-+-+-+-+-+-+-+
|   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

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           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:
```
```    + 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

SF4  = Need Authentication
SF5  = Need Authorization
WC   = Want Confidentiality

TO+  = Timeout with counter > 0
```
```   TO-  = Timeout with counter expired
UTO  = Update TimeOut
XTO  = Exchange TimeOut

Actions

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)
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.
```
```   Initiator

|    0         1         2         3         4
------+--------------------------------------------------
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
------+-----------------------------
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
------+-----------------------------
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.

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.

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.

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

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

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.  The example boundary router is 10.0.0.1.

identity local "199511@router.site" "FalDaRah"
identity remote "Happy_Wanderer@router.site" "FalDaRee"

Each mobile user adds commands to tunnel and authenticate.

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.

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.

Default: 30 minutes.  Minimum: 2 * ETO.

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

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

[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
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

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

wsimpson@UMich.edu
wsimpson@GreenDragon.com (preferred)
```
```Full Copyright Statement

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.
```