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.
|
