[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

scenario: Virtual Private Network

For discussion purposes, an administrator has two networks, and wishes
all traffic between them to be encrypted. The boundary routers are
1.0.0.1 and 2.0.0.2.

The commands to tunnel and encrypt are added. In the former router,

   route addp 2.0.0.0/8 tunnel 2.0.0.2
   secure 2.0.0.2

and in the latter router,

   route addp 1.0.0.0/8 tunnel 1.0.0.1
   secure 1.0.0.1

In each router, the lazy administrator uses the same username and
password,

   user "root" "abracadabra"

When the first datagram arrives at router 1.0.0.1 destined for net 2,
the routing table indicates that it should be encapsulated for 2.0.0.2.
However, the more specific routing table entry for 2.0.0.2 indicates
that security is required. None is currently available, so the
encapsulated datagram is tossed in the bit-bucket, and a Photuris
exchange is initiated instead.

Router 1.0.0.1 selects a random number (0x1111) and a UDP port (4097).
It hashes these together with its IP Source and the IP Destination, and
saves the hash value as its unique cookie for this exchange. A
Cookie_Request is sent to 2.0.0.2 at UDP Port 468 containing the
Initiator_Cookie.

Router 2.0.0.2 also generates a random number (0x2222) and saves it in a
global variable.

When Router 2.0.0.2 receives the Cookie_Request, it hashes the UDP Ports
(4097 and 468) together with its IP Source, the IP Destination, and its
global random number, and sends a Cookie_Response. The reply also
indicates that only Exchange Scheme 2 is offered.

When Router 1.0.0.1 receives (and validates) the Cookie_Response, it
generates a second random number with enough bits of strength for the
strongest attributes supported (default 128-bits: 0x1111...1111), and
calculates an exchange-value for Exchange Scheme 2. An Exchange_Request
is sent to 2.0.0.2 containing the scheme and value, and offering three
attributes (MD5, DES-CBC-32, DES-CBC-64).

When Router 2.0.0.2 receives (and validates) the Exchange_Request, it
also generates a second random number with enough bits of strength for
the strongest attributes supported (default 128-bits: 0x2222...2222),
calculates an exchange-value for Exchange Scheme 2, and sends an
Exchange_Response. The reply also indicates that the next steps will be
encrypted with DES-CBC-64, as well as offering three attributes (MD5,
DES-CBC-32, DES-CBC-64).

Router 2.0.0.2 begins calculating the shared-secret.

When Router 1.0.0.1 receives (and validates) the Exchange_Response, it
also calculates the shared-secret.

When Router 1.0.0.1 finishes calculating the shared-secret, it generates
a third random number for its SPI (0x12345678), and indicates an
appropriate LifeTime (300 seconds).

It chooses a Key-Generator (MD5) and a set of Attributes (MD5 and
DES-CBC-32). Based on its Identity-Choice (MD5), Identification (root),
and the secret (abracadabra), it calculates a hash over the many values
exchanged, and stores this in the Verification field.

Then, the Type through SPI fields are used as an Initialization Vector,
and DES-CBC-64 is used to encrypt the remainder of the message after the
SPI. The resulting Identification_Message is sent to 2.0.0.2.

When Router 2.0.0.2 receives (and validates) the Identification_Message,
and finishes calculating the shared-secret, it also generates a third
random number for its SPI (0xdeadbeef), indicates an appropriate
LifeTime (600 seconds), and performs the same functions described above.

In this example, the Identification and secret-key are the same for both
parties. 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, the calculation order of the fields is different
and the verification result will have a very high probability of
difference.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2