Removed old section 5.7.4 on alternative channel security protocols, and created
a new Section 3.8 describing the security services that GIST requires and where
it depends on the channel security protocol to provide them.

New text for section 3.8 as follows:

3.8.  GIST Security Services

   GIST has two distinct security goals:

   o  to protect GIST state from corruption, and to protect the nodes on
      which it runs from resource exhaustion attacks; and

   o  to provide secure transport for NSLP messages to the signalling
      applications.

   The protocol mechanisms to achieve the first goal are mainly internal
   to GIST.  They include a cookie exchange and return routability check
   to protect the handshake which sets up routing state, and a random
   SID is also used to prevent off-path session hijacking by SID
   guessing.  Further details are given in Section 4.1.3 and
   Section 4.4.1, and the overall security aspects are discussed in
   Section 8.

   A second level of protection is provided by the use of a channel
   security protocol in messaging associations (i.e. within C-mode).
   This mechanism serves two purposes: to protect against on-path
   attacks on GIST, and to provide a secure channel for NSLP messages.
   For the mechanism to be effective, it must be able to provide the
   following functions:

   o  mutual authentication of the GIST peer nodes;

   o  ability to verify the authenticated identity against a database of
      nodes authorised to take part in GIST signalling;

   o  confidentiality and integrity protection for NSLP data, and
      provision of the authenticated identities used to the signalling
      application.

   The authorised peer database is described in more detail in
   Section 4.4.2, including the types of entries that it can contain and
   the authorisation checking algorithm that is used.  The only channel
   security protocol defined by this specification is a basic use of
   TLS, and Section 5.7.3 defines the TLS-specific aspects of how these
   functions (for example, authentication and identity comparison) are
   integrated with the rest of GIST operation.  At a high level, there
   are several alternative protocols with similar functionality, and the
   handshake (Section 4.4.1) provides a mechanism within GIST to select
   between them.  However, they differ in their identity schemes and
   authentication methods and dependencies on infrastructure support for
   the authentication process, and any GIST extension to incorporate
   them would need to define the details of the corresponding
   interactions with GIST operation.