Subject: RE: [NSIS] GIST Confirm contains no stack configuration data, which holds MA_HOLD_TIME

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 28 Oct 2005 11:48:18 +0100

hi roland,

see below ...

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]] 
> Sent: 26 October 2005 16:31
> To: Hancock, Robert
> Cc: Thomas Herzog; [email-masked]
> Subject: Re: [NSIS] GIST Confirm contains no stack 
> configuration data, which holds MA_HOLD_TIME
> 
> 
> Hi Robert,
> 
> > the question of bidding down attacks is a really tricky
> > one to work through in detail. but the basic components of
> > the reasoning are as follows:
> > 
> > - if the response SCD is allowed to depend on the Query, then
> > manipulation of the Query might cause a 'weak' proposal to be
> > offered in the response. Saying that the response SCD MUST NOT
> > depend on the Query is a 'play safe' approach - you could define
> > less restrictive approaches, but actually the benefit of
> > allowing more flexibility has not been clear. you *are* able to
> > have different policies/offered SCDs for different NSLPs or
> > interfaces (e.g. 'inside' vs. 'outside'), and this would seem
> > to be sufficient (at least to me).
> 
> Yep, agreed, and I guess this point was already clear.
> Though it may be good to include the explicit hint: "you *are* able to
> have different policies/offered SCDs for different NSLPs or interfaces
> (e.g. 'inside' vs. 'outside')" in the Spec.

ok, i think this can be added as a clarification.

> 
> > - the Q-node must do a MA setup which respects the options given
> > in the response SCD. so, interfering with the response-SCD could
> > weaken the possible security properties of the MA.
> > *if* all the following conditions apply:
> > 	- a MITM can modify the response to weaken the set of offers
> > 	- the Q node policy allows the use of the weaker protocol
> > 	- the MITM is on the forward and reverse paths
> > 	- the MITM can break the weaker protocol *in real time*
> 
> Correct analysis.
> 
> > *then there is nothing further that can be done against the
> > attacker. so, the level of defence that is possible is a 
> > combination of policy setting (at the Q-node) and verification 
> > of the echoed R-SCD (at the R-node) - if the nodes have policies
> > that minimally require selection of a MA which cannot be broken 
> > in real time, then the rest of the protocol machinery will ensure
> > that any attack is detected.
> 
> So far agreed. The only criticism I had was that
> echoing the R-SCD is useless except for the situation
> where you have a MITM on the reverse path (i.e., from
> R-Node to Q-Node) and the MITM has no access to the
> forward path. So we should simply save the bandwidth
> and use it for sending back the MA-Hold-Time in an
> "empty" Stack Configuration Data.

I don't think this is quite right: an attack is possible whenever
the MITM is on the reverse path, whether or not it is on the forward
path. And the defence against the attack works whether or not the
MITM is on the forward path, provided weak policies are not used.

i think this is one of those security/complexity tradeoffs which
are so hard to make. to me, the complexity seems not so great, and
the circumstances where it is useful not so exceptional. but it 
would be interesting to hear additional voices on this one.

cheers,

robert h.

> 
> > is this discussion logically coherent? should it be in the spec?
> > (currently there is a reference to the sip-sec-agree spec, which
> > has a very similar analysis).
> 
> Oops, sorry I must have missed that one.
> However, except for the on-reverse-path-attacker-only case, I don't
> see any value in "echoing" the R-SCD (it would have a real value
> in case it was integrity protected by the Q-Node) and would plead
> for simplification.
> 
> Regards,
>  Roland
> 

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

---

From: Roland Bless <[email-masked]>
Date: Fri, 28 Oct 2005 22:35:36 +0200

Hi Robert,

> the MITM is on the reverse path, whether or not it is on the forward

Right.

> MITM is on the forward path, provided weak policies are not used.

To be more precise: the defence works because _weak_ policies
are not used. But that was not my point. Maybe I'm wrong, but
echoing the R-Node SCD does not contribute to
security if the MITM is also on the forward path and is able to
modify the confirm. The attacker cannot do anything if only
"secure" protocols are allowed by the policy, bidding down will
have no effect. In case we have proposals A,B,C and C is weak
then I see the follow attack:

       Query:
Q-Node --- A,B,C,D -> MITM - A,B,C,D --> R-Node
       Response:
       <--- C ------- MITM <-- A,B,C ---
       =========== MA C Setup =========>
       Confirm:
       ---- C ------- MITM --- A,B,C -->

I don't see how the echoed list in the confirm
lets the R-Node effectively detect that something was modified
in between. In case the R-Node proposes and accepts
only A,B (i.e. a proposal w/o weak protocols) there is no
problem anyway.

Another scenario that I described:
       Query:
Q-Node --- A,B,C,D -> MITM - A,B,C,D --> R-Node
       Response:
       <--- C ------- MITM <-- A,B  ---
       =========== MA C Setup =========>
       (this works only in case R-Node awaits
       C connections from other nodes etc.)
       Confirm:
       ---- C ------- MITM --- A,B --->

The R-Node should detect that something is wrong by
checking that the established MA C is not acceptable by
the policy for the Q-Node (this must be checked anyway).
But the echo of the Stack Proposal in the Confirm will
not bring you more security.

> are so hard to make. to me, the complexity seems not so great, and

Complexity is not a problem here, only redundancy.

> would be interesting to hear additional voices on this one.

One could argue that it may be slightly more difficult for
an attacker to manipulate the confirm than to modify the Response.
The problem is somewhat similar to the last problem mentioned in sec.
8.6.

Regards,
 Roland