Next: VSIZE Up: Protocol Specifications Previous: VNET

VSECSEL

VSECSEL ( Virtual Security Selection Protocol )

DISTRIBUTION NOTE
This protocol will not be distributed via anonymous ftp. If interested, contact xkernel-bugs@cs.arizona.edu about obtaining this protocol. SPECIFICATION
VSECSEL sits above several lower protocols, selecting them with security enhancements appropriate to the source and destination addresses of a session. In a protocol graph, VSECSEL should sit over a a key manager instance that can associate an address component with a security service.

SYNOPSIS
VSECSEL is only active during connection establishment. When openenabled, VSECSEL openenables one of its lower protocols on behalf of the upper protocol. When opened, VSECSEL opens a lower protocol, making its choice based on interactions with the key manager. The successfully opened lower session is then returned.

The default service type is the checksum service.

REALM
Since VSECSEL is active only during open, it should be considered in the same realm as the protocols below it (which should all be in the same realm.)

PARTICIPANTS
On an xOpen, VSECSEL passes the first address component of the remote participant to the key manager to select the lower security service. VSECSEL passes its participants to that lower protocol unmodified. If that service was an encryption service, then the xOpen of that service completes, VSECSEL will set the key for both the local and remote participants to be the same key.

On an xOpenEnable, VSECSEL passes the first address component of the local participant to the key manager to select the lower security service. VSECSEL passes its participants to that lower protocol unmodified.

On an xOpenDone, VSECSEL checks that the first address component of the local participant is compatible with the lower protocol. For a lower protocol that is an encryption service, VSECSEL will set the keys for the local and remote participants to be the same key. VSECSEL then passes the unmodified participants list to the upper protocol in xOpenDone.

If the selectbypart ROM option is indicated (as described below), then the first item on the stack for the remote participant is used as the security selector index. The key manager is not invoked. The selector is of type int.

CONTROL OPERATIONS
VSECSEL determines the type of control op and forwards it to the appropriate lower protocol. For example, CRYPT control ops will be forwarded to the encryption service. Other control ops will be forwarded to all lower services, but the value returned will be from the first lower protocol.

CONFIGURATION
The following entry shows how to configure vsecsel over UDP. The order of the protocols is crucial and must be correlated with the key manager file.


name=vsecsel dir=vsecsel_km files=vsecsel_km protocols=udp,md5,crypt,km/vsec;

A key manager file example is shown below. It associates UDP port 2001 (decimal) with lower protocol 1, the checksum service; UDP port 2002 with lower protocol 0, the no-security service; UDP port 2003 with lower protocol 2, the encryption service; UDP port 2004 with the checksum service. By default, the encryption service must be the third lower protocol, because the control operations to set the keys for the local and remote participants depend on it.


4 4 32
000007d1        00000001
000007d2        00000000
000007d3        00000002
000007d4        00000001

ROM OPTIONS
The keys file serves to switch sessions to the desired service. If for some reason the services are not ordered under vsecsel in the usual way, the correlation between the functionality of the service and the keys file can be set via ROM options. For example, to indicate that the first lower protocol is an encryption service:


vsecsel	private 0

The keywords sig for ``signature'', clear for no enhancements, and safe for message integrity are also available. NB that the key manager must always be the last protocol under vsecsel.

NB the following option is not fully implemented; the first component of the local participant is used, and the author intends to fix this omission at a later time. The numparts rom option is available to indicate how many participants (usually two, local and remote) are to be used in the key lookup, i.e.,


vsecsel	numparts 2

The overip rom option is available to indicate that IP addresses are being used for the determination of the security service. This allows broadcast sessions to be a separate security class. This option is not yet coordinated with the numparts option.


vsecsel	overip

The selectbypart rom option is available to indicate that higher level protocols are security cognizant and have included a participant stack member that is the index of the lower security protocol to use for open's and openenable's. In this case, the participant is popped off the stack, and other participant stack components are not examined. NB: this option affects the operation of the entire protocol; all protocols above this one must be aware that the extra participant is needed. The participant is of type int.


vsecsel	selectbypart

AUTHOR
Hilarie Orman



Next: VSIZE Up: Protocol Specifications Previous: VNET


Tue Nov 29 16:28:56 MST 1994