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

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 9 Dec 2005 09:51:48 -0000

Hi roland, all,

well, i checked to see whether the description of this point in the GIST
spec could be improved, and found that there was no description at all
:-(
i'm pretty sure something was there in previous versions, but it seems
to have got lost at some stage...

so i added a new sub-section in the security considerations. hopefully
it
is now a bit less compact.

r.

======================================================================

8.6.  Security Protocol Selection Policy

   This specification defines a single mandatory-to-implement security
   protocol (TLS, Section 5.7.3).  However, it is possible to define
   additional security protocols in the future, for example to allow re-
   use with other types of credentials, or migrate towards protocols
   with stronger security properties.  In addition, use of any security
   protocol for a messaging association is optional.  Security protocol
   selection is carried out as part of the GIST handshake mechanism
   (Section 4.4.1).

   The selection process may be vulnerable to downgrade attacks, where a
   man in the middle modifies the capabilities offered in the Query or
   Response to mislead the peers into accepting a lower level of
   protection than is achievable.  There is a two part defence against
   such attacks (the following is based the same concepts as [21]):

   1.  The Response does not depend on the Stack-Proposal in the Query
       (see Section 5.7.1).  Therefore, tampering with the Query message
       has no effect on the resulting messaging association
       configuration.

   2.  The Responding node's Stack-Proposal is echoed in the Confirm.
       The Responding node checks this to validate that the proposal it
       made in the Response is the same as the one received by the
       Querying node.  (Note that as a consequence of the previous
       point, the Responding node does not have to remember the proposal
       explicitly, since it is a static function of local policy.)

   The validity of the second part depends on the strength of the
   security protection provided for the Confirm message.  If the
   Querying node is prepared to create messaging associations with null
   security properties (e.g.  TCP only), the defence is ineffective,
   since the man in the middle can re-insert the original Responder's
   Stack-Proposal, and the Responding node will assume that the minimal
   protection is a consequence of Querying node limitations.  However,
   if the messaging association provides at least integrity protection
   that cannot be broken in real-time, the Confirm cannot be modified in
   this way.  Therefore, provided that the Querying node applies a
   security policy on the messaging association protocols it will create
   that ensures at least this minimal level of protection is met, it can
   be assured that the capability discovery process will result in the
   setup of a messaging association with the correct security properties
   as appropriate for the two peers involved.

=====================================================================

-----Original Message-----
From: Roland Bless [mailto:[email-masked]] 
Sent: 01 December 2005 16:46
To: Hancock, Robert
Cc: [email-masked]
Subject: Re: Downgrade attacks (was: RE: [NSIS] GIST Confirm contains no
stack configuration data, which holds MA_HOLD_TIME)

Hi Robert,

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

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

No problem.

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

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 police.
:-D

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

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

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

---

From: Roland Bless <[email-masked]>
Date: Fri, 09 Dec 2005 11:43:08 +0100

Hi Robert,

> spec could be improved, and found that there was no description at all

Right, that's why I was asking for more details.

> to have got lost at some stage...

That's a pity.

> r.

That sounds quite good and clear to me.

Cheers,
 Roland