[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IPSECKEY] Security Considerations



Sorry this go so big. Comments are inline.

On Thu, May 22, 2003 at 01:10:24PM -0400, Michael Richardson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> 
> >>>>> "Jean-Jacques" == Jean-Jacques Puig <Jean-Jacques.Puig@int-evry.fr> writes:
>     Jean-Jacques> On Tue, May 20, 2003 at 05:51:22PM -0400, Michael Richardson wrote:
>     >> >> If the attacker was not able to subsequently mount a second man-in-
>     >> >> the-middle attack on the IKE negotiation, then this would result in a
>     >> >> denial of service, as the authentication used by IKE would fail.
>     >> >> 
>     >> >> If the attacker was also in a position to perform a man-in-the-middle
>     >> >> attack on IKE and IPsec negotiations as well, then it would be a
>     >> >> position to compromise the resulting IPsec channel.  Note that an
>     >> >> attack must be able to perform active DNS attacks on both sides of
>     >> >> the IKE negotiation in order for this to succeed.
>     >> 
>     Jean-Jacques> I see your point, but is it expected that IKE initiator and responder
>     Jean-Jacques> will both use IPSECKEY RR ? I think asymetric scenarios may happen
>     Jean-Jacques> (initiator using IPSECKEY and responder an other scheme).
>     >> 
>     >> That's true. I have certainly done this in the past!
>     >> Both ends *do* need to have their public key's spoofed to get in the middle.
>     >> 
> 
>     Jean-Jacques> Sorry, I don't know if I was clear about why I was talking about that.
>     Jean-Jacques> In the (latests) SC sentence: 
> 
>     >> Note that an attacker must
>     >> be able to perform active DNS attacks on both sides of the IKE
>     >> negotiation in order for this to succeed.
> 
>     Jean-Jacques> I think we should only state:
> 
>     >> Note that an attacker must
>     >> be able to perform active attacks on both sides of the IKE
>     >> negotiation in order for this to succeed.
> 
>     Jean-Jacques> An active DNS attack against at least one side is what this
>     Jean-Jacques> security consideration deals with. The active attack on the other side
>     Jean-Jacques> depends on the other channel elected to get public key. This may be
> 
>   Okay, let me setup my classic nomenclature to explain:
> 
>                              [Q]    [R]
>                               .      .              AS2
>      [A]---------[SG-A].......+.[M]..+.......[SG-B]-------[B]
>             |                 ........
>                               ..PI....
>                               ..wild..
>                              .+.......+......[SG-C] AS3
> 
> 
>   Assume that we have:
> 
> 	 A.in-addr.arpa.	IN IPSECKEY ( 10 1 5 SG-A SG-A's-KEY )
> 	 B.in-addr.arpa.	IN IPSECKEY ( 10 1 5 SG-B SG-B's-KEY )

Ok, I see where we failed to understand each others. The difference is I
assume the *general case* we consider is where IPSECKEY information is
available for one peer, while the other peer may use other unsecure ways
to get public keys (let's say a floppy with raw unauthenticated datas).

That is, I assume we may have something like:

 	 A.in-addr.arpa.	IN IPSECKEY ( 10 1 5 SG-A SG-A's-KEY )  (a)
	 SG-B's-KEY and delegation(B->SG-B) on a floppy				(b)

I surely agree that M must perform two active attacks.
The first one is a *DNS* active attack against SG-B, in which M provides
the kind of following info instead of (a): A.in-addr.arpa.	IN IPSECKEY (10 1 5
SG-A SG-M's-KEY ).
The second active attack if a... *FLOPPY* active attack against SG-A :).
That is, M substitutes a floppy providing SG-M's-KEY and delegation(B->SG-M).

	The difference between our views on the subject (IMHO) is that you
	consider the general case is where SG-A and SG-B will both use
	IPSECKEY RR, while for me the general case relevant to IPSECKEY RR
	is where (at least) either SG-A or SG-B uses IPSECKEY RR. Therefore,
	for me, the two above mentionned active *DNS* attacks are -in my
	general case- merely two active attacks.
> 
> 
>   Now, assume that SG-A's doesn't get this record, but instead gets:
> 
> 	 B.in-addr.arpa.	IN IPSECKEY ( 10 1 5 SG-B SG-M's-KEY )
> 
>   that's is, just the KEY is changed.
>   We then see:
> 	  [SG-A] <===IKE========>[M]<===IKE==>[SG-B]
> 
>   That is, M pretends to be SG-B to SG-A, and vica-versa.
>   Since SG-A has M's key instead of SG-B's key, SG-A is easily fooled into
> thinking it is speaking to SG-B.
> 
>   However, if as you postulate, SG-B has SG-A's key in a secure fashion, 

In fact, what I postulate is that SG-B gets SG-A's key in an unsecure
fashion which may be something else than IPSECKEY RR, like the floppy disk
above. Sorry about being unclear about that. I came to consider this
asymetry because I think several scheme to retrieve public keys will
appear in the wild, and given this plurality, chances that both
initiator and responder use IPSECKEY RR may be low.

> then the second IKE transaction, where M pretends to be SG-A, fails. SG-B 
> doesn't believe M, since it has SG-A's proper key.
>   As such, it won't negotiate, and while SG-A may send traffic to M, M
> will be unable to forward it to SG-B.
> 
>     Jean-Jacques> Note also that in the present case, the attacker is in position to
>     Jean-Jacques> modify phase 1 payloads to force choice of identities, kind of
>     Jean-Jacques> authentication, etc. All of this may affect the choice of channels
>     Jean-Jacques> elected to get the public keys.
> 
>   Yes/no.
>   It certainly can do that. The phase 1 info is authenticated after the
> privacy is established, so the authentication will fail. 

Because M provided wrong responder key to SG-A through un-(integrity
protected) ipseckey rr, M is able to recompute the kind of message from
IKE's phase1 with public key encryption:
HDR, KE, [ HASH(1), ] <IDii_b>PubKey_r,<Ni_b>PubKey_r (mesg 3)
Thus, M is able to annonce a different IDii. According to the type of
IDii, the responder may try to get public key of SG-A, and get fooled by
the false IDii provided by M.

> 
>     Jean-Jacques> Please, if I'm wrong, may someone explain why active DNS attacks MUST
>     Jean-Jacques> be performed against BOTH sides in this case.
>   
>   I hope that the above explains it.
> 
> >>>>> "Jean-Jacques" == Jean-Jacques Puig <Jean-Jacques.Puig@int-evry.fr> writes:
>     >> packets to the original destination.  While the destination may be
>     >> willing to speak in the clear, replying to the original sender, the
>     >> sender would have already created a policy expecting ciphertext.
>     >> Thus, the need for attacker to intercept traffic from both sides.
> 
>     Jean-Jacques> Though it is not usefull to mention it in the draft, I think
>     Jean-Jacques> the attacker may achieve easily this interception:
>     Jean-Jacques> 1) Attacker provides a wrong IPSECKEY RR with it's own gateway through
>     Jean-Jacques> DNS cache poisonning.
> 
>     Jean-Jacques> 2) Initiator establishes tunnel with attacker's gateway.
> 
>   Yes. Let's call initiator "A".
> 
>     Jean-Jacques> 3) Initiator sends packets to Destination through tunnel.
> 
>   Yes. Let's call destination "B", and attacker "M"
> 
>     Jean-Jacques> 4) Attacker masquerades source address of packets coming through the
>     Jean-Jacques> tunnel, and forwards them to Destination.
> 
>   Do you mean performs NAPT or NAT?

basic-nat (NAT).

> 
>     Jean-Jacques> 5) Destination answers to the masqueraded address (the attacker)
> 
>     Jean-Jacques> 6) Attacker masquerades destination address of packets coming from
>     Jean-Jacques> Destination, and forwards them through the tunnel, etc.
>     Jean-Jacques> Attackers main difficulty is then to deal with transport checksums and
>     Jean-Jacques> application datas containing endpoint addresses or names.
> 
>   Trivial, I think, since NAT technology is widely available, and there are few
> protocols which are in widespread use that do not have NAPT support.
> 
>   Note that the destination (B) logs a connection from the attacker (M).
>   It also has no security, and knows it has none. 
>   Since it was willing to speak in the clear in this case, I would expect
> that it already thinks life is fine with being spoofed. 
> 
>   M could also initiate to B, at which point B knows that it has a tunnel
> to M, not to A. It could even be the case that B knows M is M securely (DNSSEC).
> 
>   The concern is naturally that "A" thinks that it is speaking securely to
> "B".  It  may reveal passwords, etc. to M.  It has been spoof'ed by M. Is
> this a new attack? Not really to me.

No, of course it is not new, we all know that, and discussion about SC is
mostly about stating what we think we already know ;-)). But:

>    While the destination may be
>    willing to speak in the clear, replying to the original sender, the
>    sender would have already created a policy expecting ciphertext.
>    THUS, THE NEED FOR ATTACKER TO INTERCEPT TRAFFIC FROM BOTH SIDES.

According to this sentence, one may think that M MUST be on 'the'
route a packet would 'naturally' follow to go from SG-A to SG-B.
This is not required: By providing it's own security gateway through the
RR to the initiator, M both get a way to be IKE's responder and to
intercept the packets, even if he was not on the classical route between
SG-A and SG-B initially. M must then make sure he will get answers
destined to A. He may proceed according one of the following ways:
- by establishing a tunnel with SG-B, with the hope that SG-B will
  accept the odd policy that M is the gateway for A (but how can SG-B
  tell if no delegation info exist for A ?). If it works, M only
  forwards packets from A to B through the tunnel.
- by doing basic-nat, changing A address by an address on which he has
  full control. Classical routing will then help him to get the answers.

Thus, I certainly agree with what this sentence says and with your comments,
but what I want to underline is that this attack does not require M to be
on a specific location (that is, on a specific route), and therefore is
PARTICULARLY easy to perform because M can specify a wrong address for
SG-B in the RR. 

Note that in the case SG-B does not accept the previous policies
('clear-text' or 'M is gateway for A'), it remains the case where M and
A are remote warriors from SG-B's network. With a combination of both
basic-nat and tunnel establishment with SG-B, M performs the attack.

Well anyway, I was only questioning the accuracy of the above
consideration, but I agree I do hairs splitting here :), and that it
reaches the frontiers of the charter.

--
Jean-Jacques Puig
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.