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

scenario: Multi-User Access Control

In certain extremely security conscious environments, all valid users
sharing a node might not have the same level of authorization. The
operating system itself is not the trusted entity. Each user or process
requires its own identification and access control. These "Multi-Level
Secure" environments require two or more Photuris exchanges.

These exchanges involve 4 or more entities:

   user "myself@SomeWhere"  "mairsydotes"
   user "rcmd@SomeWhere"    "doesydotes"
   user "myself@ElseWhere"  "liddellams"
   user "rcmd@ElseWhere"    "eedivy"

The first Photuris exchange might be triggered when sending a datagram
from SomeWhere to ElseWhere. The Initiator would naturally use the
Identification which is associated with the triggering transport-level
process (myself@SomeWhere).

Because Photuris is a network-level session key management protocol, the
Responder Identification will be associated with the operating system
which is processing the network-level exchange (rcmd@ElseWhere). Since
authentication policy is in the receiver direction, when datagrams
arrive at ElseWhere with the given SPI, the access policy will be
dependent on the Initiator Identification.

Likewise, when datagrams arrive at SomeWhere with the given SPI, the
access policy will be dependent on the Responder Identification. This
may not match the authorization level required for access. This is
indicated by the ICMP message Security Failures: Need Authorization
(Type 40, Code 5).

The Responder in turn becomes the Initiator in a second exchange, and
delivers the Identification which is associated with the triggering
transport-level process (myself@ElseWhere). The peer might use its
system-wide Identification (rcmd@SomeWhere).

When repetitive Photuris exchanges occur between the same parties, and
the exchange-values are discovered to be unchanged, the cached
shared-secret can be used to rapidly generate new session-keys.

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