Re: [NSIS] AD review: draft-ietf-nsis-ntlp-09: M2 Security Issues

[Magnus Westerlund <[e-mail]>]

Hancock, Robert wrote:
> 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.

Hmmm. I see that being easily done for the MA that are established over 
connection oriented protocols. What about applications using D-mode for 
application data?

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

Yes, maybe I am being overly paranoid here. And it seems that if you 
like to authenticate the D-mode requests you could use IPsec AH mode to 
accomplish that. However lets assume that this is sufficient for now. I 
intended to request a security review of this protocol as soon as we are 
ready to progress GIST to IETF last call.

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

Yes. But with the extra twist that I perceive a threat of spoofing or 
manage to tunnel attacks into the domain. Thus having a desire to 
restrict the interior nodes to only accept GIST D-mode messages that are 
authenticated as coming from a the domain. But I will assume that this 
can actually be accomplished with IPsec.

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

I think you are mostly correct. However I think there is a case D that 
is not sufficiently warned about. The case is the two GIST peers A and 
B, where A tries to create a MA between them. The attacker C is on-path 
and can intercept and rewrite the GIST messages. A offers both TCP/TLS 
and TCP in its query. C change that to only being TCP. Which it can sit 
in the middle and rewrite anything in. B. gets the modified query and 
sends a response. The response sent back by C is modified so that A gets 
  the picture that B selected TCP. The TCP connection is established and 
now C can modify the checks as they are not secured.

My issue with this whole thing is that the only way of knowing that a 
MITM exist is to require the usage of TLS with certs at both end, and 
use that to verify the query sent unsecured. I think it should be 
clearer that not having a policy of using TLS equals leaving it open for 
MITM. Or is the above case based on some misunderstanding?

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]

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