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

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 2 Jun 2006 12:22:14 +0100

Hi,

the security issues, M2:

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: 01 June 2006 15:23
> To: [email-masked]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: <[email-masked]>
Date: Fri, 2 Jun 2006 15:14:23 +0300

Hi all,
>use TLS or whatever). This can use traditional cryptographic 
>security techniques. So there should be no d-mode security issue here.
>
>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 

I agree with Robert's analysis here.  Magnus, do you feel that anything
should
be added to the Security Considerations (that is not already there)
on this issue?

>> 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.
>
>- a host initiates the GIST handshake with the appropriate 
>edge node, sets up routing state and a messaging association
>- 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). 
>

Agreed - this is a sort of a deployment considerations topic, depending
upon what kind of network you are looking at.  I'm not sure if this
would
go into a base spec, but maybe a deployment guide, BCP or applicability
statement, IMO.

>- IF you have a suitable security policy and credentials at 
>each node (and 8.6 explains what 'suitable' means)
>(b) allow a properly secured MA which it cannot intercept The 
>MitM cannot do

Robert, I'm not sure if I can exactly parse (b), though I get your
point ...

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

Again, I agree with Robert's analsys here - do we need any additional
text?

John

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Jun 2006 14:13:33 +0200

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

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

> 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 +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]