RE: [NSIS] AD review: draft-ietf-nsis-ntlp-09

["Hancock, Robert" <[e-mail]>]

Hi,

the security issues, M2:

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]] 
> Sent: 01 June 2006 15:23
> To: [e-mail]
> Subject: [NSIS] AD review: draft-ietf-nsis-ntlp-09
> 
> M2. Security functions for d-mode
> 
> When reading the security consideration and the specification on 
> security properties I get a bit frightened that there are no 
> authentication mechanism specified for d-mode. It seems that there 
> should be need for authentication of d-mode queries etc to 
> ensure that 
> the a NSIS node is talking to someone that really has the right to 
> perform the query and association creation. 

This is an important question. Some high level analysis:
*) d-mode basically has two functions: 
- to set up routing state
- to set up messaging associations

Authentication/authorisation of the 'right' to set up the MAs
is actually handled within the MA protocols themselves (if you 
use TLS or whatever). This can use traditional cryptographic security
techniques. So there should be no d-mode security issue here.

Authentication/authorisation of the 'right' to set up routing
state is a more tricky. The point is that there is no framework 
within which the correctness of routing state can be secured in
the traditional sense. Whether or not a node is on the route
of a flow is a dynamic function of the forwarding tables in the
network as a whole; two nodes could authenticate with each other
all that they want to, but this would tell us nothing about 
whether the routing state itself was correct, since that can only
be done by interaction with the forwarding layer. A further point
is that at the start of the d-mode exchange, you can no idea
which peer you are going to be communicating with, so at least
some unauthenticated discovery phase would be needed anyway.
The GIST design is supposed to restrict the scope of d-mode
to this initial phase, and move over directly to c-mode as soon
as it is meaningful to do so.

Section 8.3 is supposed to be about the sort of 'non-cryptographic' 
authentication which can/must be done in these circumstances.

> Not having such a 
> mechanism 
> seems to prevent building a system where the domains edge 
> nodes handles 
> the primary security and the internal nodes only accept GIST messages 
> that are authenticated by nodes belonging to the domain.

I don't understand the problem here. There is nothing to stop
a domain being deployed with the security model you indicate; for
example:
- a host initiates the GIST handshake with the appropriate edge
node, sets up routing state and a messaging association
- the edge node authenticates the host as part of the MA setup
and decides what the host is allowed to do
- the host initiates some signalling application transaction
- if the edge node decides the signalling transaction is valid, 
it continues to execute the transaction on the domain interior
nodes (GIST handshake for route discovery followed by a signalling
application exchange; typically the necessary MAs would already
be in place). 

is this the sort of model you are thinking about?

> 
> Section 8.6: I also am concerned that if there exist no secured MA 
> between two GIST nodes, a on-path Man in the middle can prevent there 
> from ever existing a secured MA.

This is not what 8.6 is aiming at. Modulo the residual threat
in 8.7, 8.6 is saying that
- IF you have a suitable security policy and credentials at each node
(and 8.6 explains what 'suitable' means)
- THEN the only things that an on-path MitM can do are 
(a) prevent all communication
(b) allow a properly secured MA which it cannot intercept
The MitM cannot do
(c) allow an insecure MA which it can intercept

(a) is not something that any security solution can prevent: an on-path
MitM can always just block traffic. (b) is the desired outcome anyway.
What is ruled out is (c), which is a consequence of the MitM detection
mechanism in the Confirm and the security policy which says what to do
if the MitM is detected. (Basically, any attempt to set up an insecure
MA is automatically detected as an MitM attack.)

cheers,

robert h.


_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis