Subject: Downgrade attacks (was: RE: [NSIS] GIST Confirm contains no stack configuration data, which holds MA_HOLD_TIME)

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 1 Dec 2005 15:50:10 -0000

[changed the subject line to attract new readers ;-) ]

hi roland,

apologies for the belated reply. i never find this topic easy
to analyse.

i think i could summarise your argument as:
"if the Q-node applies a strong security policy, a MITM will
never be able to persuade it to set up an insecure MA at all;
if it applies a weak security policy, an MITM will be able to
modify the echoed R-node proposal in the Confirm. in either
case, echoing the R-node proposal in the Confirm provides no
added value."

i believe this argument is not complete, because actually there
is a range of policies that the Q-node could apply (not just
the choice "totally secure" vs. "nothing").

first, a concrete example: take 4 MA possibilities
A: a 'perfect' MA (TLS with AES ciphering/integrity protection,
   for example)
B1: an authenticated integrity-only MA (say TCP-MD5)
B2: a 'weakly secure' MA (e.g. something restricted to 40bit RC4)
C: a trivial MA (TCP only).

the Q and R nodes support all of them. the Q node wants to use
A if possible, but realises that not all peers will always offer
it (resource or regulatory constraints); however, the Q node
is able to enforce a policy "don't use C" for some of its 
interfaces.

consider a Q-R handshake with an MITM who wants to read the
signalling messages.

Query: Q --> (A, B1, B2) --> MITM --> (A, B1, B2) --> R

The responder node will offer all the possibilities, but
the MITM wants to ensure A is not used (it can read the
traffic directly if B1 is used, or break it off-line if B2
is used), so we have:

Response: Q <-- (B1, B2, C) <-- MITM <-- (A, B1, B2, C) <--R

The Q-node discards the option C (policy constraint) and
sets up an MA with B1 or B2 as the security mechanisms

   Q <================ MA setup (B1/B2) ==============> R

If this is as far as it goes, the MITM has succeeded: A
was available to both parties, but they didn't use it; instead,
there is a security association in place but which doesn't
protect the signaling data from interception (in real-time,
for B1, or off-line decryption, B2).

However, if we echo the R-node proposal in the Confirm, 
we have

Confirm: Q --> (B1, B2, C) --> MITM --> (B1, B2, C) --> R
(the MITM can't break the integrity protection provided by
B1 or brute-force the key used in B2 within a single RTT)
et voila: R will detect the downgrade attack and call the
police.

so this is the combination of (type of attack, security
policy) that we are trying to prevent. a way of stating this
would be:

"without the echo of the R-node proposal in the Confirm, an
MITM can bid the level of security protection down to the
weakest policy that the Q-node accepts. with the echo of the
R-node proposal in the Confirm, the Q-node only needs to
enforce a minimal security policy [require integrity protection
that cannot be broken in real-time] to ensure that the optimal
level of MA security protection supported by both nodes is
actually used."

is this correct?

robert h.

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]] 
> Sent: 28 October 2005 21:36
> 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,
> 
> > 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
> 
> Right.
> 
> > path. And the defence against the attack works whether or not the
> > 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.
> 
> > 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
> 
> Complexity is not a problem here, only redundancy.
> 
> > the circumstances where it is useful not so exceptional. but it 
> > 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
> 

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

---

From: Roland Bless <[email-masked]>
Date: Thu, 01 Dec 2005 17:45:46 +0100

Hi Robert,

> [changed the subject line to attract new readers ;-) ]
:-)

> apologies for the belated reply. i never find this topic easy

No problem.

> B1 or brute-force the key used in B2 within a single RTT)

Ok, right. I guess the sentence in parentheses is exactly what
I was missing. In my scenario the MITM was able to re-establish
the original proposal:
Confirm: Q --> (B1, B2, C) --> MITM --> (A, B1, B2, C) --> R
This would be possible if B1,..,C are too weak.
So I think it is an important point and must be mentioned.

> et voila: R will detect the downgrade attack and call the
:-D

> level of MA security protection supported by both nodes is

Yep. But it's written rather compact. I'm not sure whether it's getting
clear that the essential point is the integrity protection of the
Confirm by the MA that prevents modification of the echoed proposal.

Regards,
 Roland