[NSIS] GIMPS issue #10 (NSLP/GIMPS security interface)

["Hancock, Robert" <robert.hancock at roke.co.uk>]

Hi all,

There has been a long standing issue about the GIMPS API of
how to capture the security interactions between the layers
(i.e. how NSLPs can request/be aware of GIMPS security
services).

I added a proposed resolution to the issue tracker; the
text is reproduced below. It's worth pointing out that this 
issue has no effect on the GIMPS protocol itself. It only 
affects the API, and the ability of NLSPs to specify formally
how they want to use the security services provided by GIMPS.

robert h.

http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue10:

The [channel] security functionality of GIMPS includes the selection of
channel
security protocols, the selection and setup of security associations with
those
protocols, as well as actually sending and receiving messages under the
protection of the channel security protocol.

In principle, a full design of the NSLP/GIMPS interface could cover all
these
issues, in the sense that the sensible choice of security association (for
example) might depend on NSLP opinions about how it would be used. However,
the
first two items can be considered a fairly pure local policy issue for the
GIMPS
implementation internals, which only become relevant to the signalling
applications when NSLP-data is actually transferred. A full policy framework
for
controlling how GIMPS manages channel security is liable to be very complex.

For this reason, the proposal is to extend the API to cover purely the
question
of what security attributes are associated with an individual message
transfer.
The attributes would be (roughly): authenticated source and destination
identities and level of security protection applied from {confidentiality,
integrity}.

On receiving a message, the NSLP can be told explicitly what the security
attributes are.

On sending a message, the NSLP could specify the required attributes
explicitly
(e.g. as being the same as a previously received message). In some cases,
this
won't be possible, typically because at the time the NSLP requests a message
to
be sent the peer authentication (during messaging association setup) won't
even
have taken place. In this case, once the MA setup has completed, we can
allow a
callback to the NSLP to allow it to abort sending the message if it doesn't
like
the security attributes available.

Where there is a choice of attributes (e.g. a choice of local identities to
use
when sending a message), we assume either that GIMPS will 'guess right'
through
its internal policy (and allow the NSLP to approve the choice through the
callback mechanism), or that the NSLP has explicitly selected what
attributes to
use by copying them from a previous transaction.

_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis