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

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 26 Oct 2005 12:52:23 +0100

hi roland, thomas,

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

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

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

robert h.

> -----Original Message-----
> From: Thomas Herzog [mailto:[email-masked]] 
> Sent: 25 October 2005 16:38
> To: Roland Bless
> Cc: Hancock, Robert; [email-masked]
> Subject: Re: [NSIS] GIST Confirm contains no stack 
> configuration data, which holds MA_HOLD_TIME
> 
> 
> Hi, Roland,
> 
> exactly, what I meant, too.
> 
> Am Dienstag, 25. Oktober 2005 17:25 schrieb Roland Bless:
> 
> > I think it is more interesting to be able to detect the
> > selection of a weak protocol. For instance, if both nodes offer
> > TLS/TCP and TCP but only TCP is selected that should make
> > the R-Node suspicious. However, according to the policy TCP
> > is acceptable anyway. So I don't see a reason to repeat
> > the R-Node's Stack Proposal. Maybe someone else could elaborate
> > what "certain bidding down attacks" means. Currently I don't
> > see any real value in it.
> 
> To my understanding, even this case (selection of a weak 
> protocol) is not 
> really useful.
> 
> As the Message Transfer security is set by the NSLP which 
> called SendMessage 
> with "transfer-attributes=secure/reliable", it is also 
> possible that the NSLP 
> would NOT have required security (e.g. set only "reliable").
> 
> In this case, both nodes still send their full set of 
> proposals, but the 
> Q-Node is then free to use a "weak" connection.
> 
> (The Q-Node would include it's full ability set, because it 
> could be that the 
> R-Node local policy would require secure connections)
> 
> So selecting a "weak" Profile in case both nodes can support 
> more secure ones 
> can't be an error according to the spec.
> 
> Cheers, Thomas
> 

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

---

From: Roland Bless <[email-masked]>
Date: Wed, 26 Oct 2005 17:30:55 +0200

Hi Robert,

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

> 	- the MITM can break the weaker protocol *in real time*

Correct analysis.

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

> 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