%
% $RCSfile: bind.tex,v $
%
% $Revision: 1.1 $
% $Date: 1995/07/28 21:15:10 $
%

\protspec{BIND}{BIND (A Layered Encryption Key Manager)}
\index{bind}
\label{BIND}

\input cryptDist

\topic{SPECIFICATION}

\noindent
BIND sits on top of an instance of the KM protocol and 
maps a participant to a id which is then used by the KM 
to provide a key.  

\topic{SYNOPSIS}

\noindent As we have discovered in decomposing Kerberos, any binding 
between network addresses and keys can be very transient. The 
BIND protocol was designed to be inserted between CRYPT and 
KM to manage temporary bindings. Thus the KM data base will 
contain name to key bindings while the BIND data base will 
contain address to name bindings. CRYPT will open a BIND 
session just as it would a KM session. When the address to 
name  mapping is set (through calling a KM\_SET or BIND\_SET  
control op) BIND will open a KM session using the name as its 
participant. When CRYPT performs a KM\_RESLOVE on the BIND 
session it in turns perform a KM\_RESLOVE on the 
corresponding KM session. 

\noindent In this organization the KM data base is fairly stable and 
managed via a separate key management protocol suite.  The 
address name bindings are set by performing a CRYPT\_IN(or 
OUT)\_SET on the appropriate session with  the name which 
corresponds to this session. Note names in this  version are 
fixed length byte strings. 

\noindent Note that a KM\_RESLOVE on BIND gets you a key from the KM 
data base while a KM\_SET takes a name not DES key. This is 
not symmetric and exists only to support Kerberos.

\noindent Names are simply fixed length byte strings.

\noindent The keys file name is formed by concatenating the strings 
``bindings'' with the instance name of the protocol (which may 
be null).

\noindent 
\topic{REALM}

\noindent BIND is in the ASYNC realm.

\topic{PARTICIPANTS}

\noindent BIND accepts participants in order to do a table lookup to find 
the key. The entire participant list is converted into a byte 
string which is then used to lookup the key. 

\topic{CONTROL OPERATIONS}

\begin{description}
\item [BIND\_RESOLVE] returns a copy of the name stored in that session. 
This name is the name which is associated with the participant 
list passed at open time. BIND can fail if no key has been set or 
that key has been invalidated.

\item [BIND\_SET] sets the name for that session to the value passed.

\item [BIND\_INVALIDATE] marks the name as invalid and removes the BIND 
session from the map. The session is not destroyed until all 
users of that session have closed it. 

\item [BIND\_ISEMPTY] succeeds if no name for this session has been 
defined.  

\item [BIND\_ISVALID] succeeds if there is a valid name for this session. 

\item [BIND\_ISINVALID] succeeds if a BIND\_INVALIDATE operation has 
been performed in this session. 
\end{description}

\noindent BIND also supports all of the KM control operations. 
The only two which should ever be used are:

\begin{description}
\item [KM\_RESOLVE] performs a KM\_RESLOVE on the corresponding 
KM session. (ie it returns a DES key not a name).  

\item [KM\_SET] is identical to BIND\_SET.
\end{description}

\topic{CONFIGURATION}

\noindent BIND must be configured on top of KM and any protocol which uses KM can 
use BIND. 

\topic{KEY FILES}

\noindent BIND key files are identical to KM key files.

\medskip

\topic{AUTHOR}

\noindent Sean W. O'Malley