Subject: [IPSECKEY] Security Considerations

From: Michael Richardson <[email-masked]>
Date: Tue, 20 May 2003 15:32:39 -0400

4. Security Considerations

   This entire memo pertains to the provision of public keying material
   for use by key management protocols such as ISAKMP/IKE (RFC2407) [7].

   The IPSECKEY resource record contains information that MUST be
   communicated to the end client in an integral fashion - i.e.  free
   from modification.  The form of this channel is up to the consumer of
   the data - there must be a trust relationship between the end
   consumer of this resource record and the server.  This relationship
   may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to
   another secure source, a secure local channel on the host, or some
   combination of the above.

   The keying material provided by the IPSECKEY resource record is not
   sensitive to passive attacks - it may be freely disclosed to any
   party without any impact on the security properties of the resulting
   IPsec session: IPsec and IKE provide for defense against both active
   and passive attacks.

   An active attack against this record, were it not provided with end-
   to-end integrity, would provide an opportunity for an attacker to
   replace the keying material.

   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.

   The semantics of when to use this record is outside of the scope of
   this document.  Any user of this resource record MUST carefully
   document their trust model, and why the trust model of DNSSEC is
   appropriate, if that is the secure channel used.

-
This is the [email-masked] list.
Email to [email-masked] to be removed.

---

From: Jean-Jacques Puig <[email-masked]>
Date: Tue, 20 May 2003 22:40:53 +0200

Wow, it got huge !

>    for use by key management protocols such as ISAKMP/IKE (RFC2407) [7].

A question regarding the charter ipsec-specific scope: obviously, the
IPSECKEY RR public key is for use with a key management protocol (KMP).
But I came to wonder about what means 'ipsec-specific' ? Does this means
that the KMP belongs to the ipsec protocols suite (this is how I
understand it) or does this means that it is for use for a KMP that is
able to set up ESP or AH SAs ? By the way, do we mean that the DOI of the
key management protocol (KMP) in phase 2 (if applicable) is IPsec ?

>    combination of the above.

May be the first thing we should focus on now is to reach for a
consensus about if end to end integrity is REQUIRED or RECOMMANDED.

>    IPsec session: IPsec and IKE provide for defense against both active

Do we really need to speak about IPsec and IKE here ? The RR datas are
expected to be public and as such are implicitly unsensitive to passive
attacks.

>    replace the keying material.

What about the gateway ? By providing his own gateway (with a suitable
key or with an ipseckey rr for the gateway), wouldn't the attacker
manage to reroute destination packets to him thanks to the tunnel ?
Would this help to set up a MiM ?

>    the IKE negotiation in order for this to succeed.

I see your point, but is it expected that IKE initiator and responder
will both use IPSECKEY RR ? I think asymetric scenarios may happen
(initiator using IPSECKEY and responder an other scheme).

--
Jean-Jacques Puig
-

---

From: Rob Austein <[email-masked]>
Date: Tue, 20 May 2003 16:39:37 -0400

I'll defer to all the Real Security Geeks in the (virtual) room on
whether the analysis is technically correct, but the revised Security
Considerations look pretty good to me.

Nits:

>    If the attacker was not able to subsequently mount a second man-in-

s/was/were/

>    If the attacker was also in a position to perform a man-in-the-middle

s/was/were/

>    attack on IKE and IPsec negotiations as well, then it would be a

s/it would be/the attacker would be in/

>    attack must be able to perform active DNS attacks on both sides of

s/an attack/an attacker/

>    appropriate, if that is the secure channel used.

No objection to what I think is the intent of the text here, but
"semantics" just doesn't sound right in this context.  I'm page
faulting on what the right word would be, it's somewhere in the
neighborhood of "implementation and operational policy decision", but
I haven't thought of the right word yet.  Leave it as it stands if
nobody can think of a better way of phrasing this, but I suspect that
the current phrasing is going to confuse people.

Thanks!
-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 20 May 2003 17:45:32 -0400

>> The IPSECKEY resource record contains information that MUST be

  I meant to write "SHOULD" here.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-
This is the [email-masked] list.
Email to [email-masked] to be removed.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 20 May 2003 17:51:22 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Jean-Jacques" == Jean-Jacques Puig <[email-masked]> writes:
    Jean-Jacques> A question regarding the charter ipsec-specific scope: obviously, the
    Jean-Jacques> IPSECKEY RR public key is for use with a key management protocol (KMP).

  Yes.

    Jean-Jacques> But I came to wonder about what means 'ipsec-specific' ? Does this means
    Jean-Jacques> that the KMP belongs to the ipsec protocols suite (this is how I
    Jean-Jacques> understand it) or does this means that it is for use for a

  Yes. It would be IKE, IKEv2, and perhaps Photoris (if you can find any).
  KINK/IKE would not use public keys directly (the KDC might), so this doesn't matter.

    >> IPsec session: IPsec and IKE provide for defense against both active

    Jean-Jacques> Do we really need to speak about IPsec and IKE here ? The RR datas are
    Jean-Jacques> expected to be public and as such are implicitly unsensitive to passive
    Jean-Jacques> attacks.

  SC is mostly about stating what we think we already know :-)

    >> replace the keying material.

    Jean-Jacques> What about the gateway ? By providing his own gateway (with a suitable
    Jean-Jacques> key or with an ipseckey rr for the gateway), wouldn't the attacker
    Jean-Jacques> manage to reroute destination packets to him thanks to the tunnel ?
    Jean-Jacques> Would this help to set up a MiM ?

  Yes, they could do that.
  Does this need to be stated.

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

---

From: Jean-Jacques Puig <[email-masked]>
Date: Thu, 22 May 2003 10:06:29 +0200

>   Both ends *do* need to have their public key's spoofed to get in the middle.

Sorry, I don't know if I was clear about why I was talking about that.
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.

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.

An active DNS attack against at least one side is what this
security consideration deals with. The active attack on the other side
depends on the other channel elected to get public key. This may be
also DNS (in which case, the other active attack is also against DNS),
or PKI, relation to a crypto-based address, keys shared on a mounted
filesystem, pieces of paper with hand-written keys, etc.
Note also that in the present case, the attacker is in position to
modify phase 1 payloads to force choice of identities, kind of
authentication, etc. All of this may affect the choice of channels
elected to get the public keys.

Please, if I'm wrong, may someone explain why active DNS attacks MUST
be performed against BOTH sides in this case.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 22 May 2003 13:10:24 -0400

-----BEGIN PGP SIGNED MESSAGE-----

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

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

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

    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.

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

    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.

---

From: Jean-Jacques Puig <[email-masked]>
Date: Fri, 23 May 2003 11:14:34 +0200

Sorry this go so big. Comments are inline.

>      [A]---------[SG-A].......+.[M]..+.......[SG-B]-------[B]

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

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

>   Do you mean performs NAPT or NAT?

basic-nat (NAT).

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 May 2003 10:02:07 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Jean-Jacques" == Jean-Jacques Puig <[email-masked]> writes:
    Jean-Jacques> Ok, I see where we failed to understand each others. The difference is I
    Jean-Jacques> assume the *general case* we consider is where IPSECKEY information is
    Jean-Jacques> available for one peer, while the other peer may use other unsecure ways
    Jean-Jacques> to get public keys (let's say a floppy with raw unauthenticated datas).

  I'm not sure I'd call a floppy unauthenticated, but I understand that you
are saying that M can not mount an online attack against B.

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

  This depends a lot upon how you use IPSECKEY, I guess.
  Are you assuming that M is also impersonating B's IP?

  I agree that this is a man-in-the-middle attack. It is what happens when
you use unauthenticated data :-)
  
    >> this a new attack? Not really to me.

    Jean-Jacques> No, of course it is not new, we all know that, and discussion about SC is

    >> THUS, THE NEED FOR ATTACKER TO INTERCEPT TRAFFIC FROM BOTH SIDES.

    Jean-Jacques> According to this sentence, one may think that M MUST be on 'the'
    Jean-Jacques> route a packet would 'naturally' follow to go from SG-A to SG-B.
    Jean-Jacques> This is not required: By providing it's own security gateway through the
    Jean-Jacques> RR to the initiator, M both get a way to be IKE's responder and to
    Jean-Jacques> intercept the packets, even if he was not on the classical route between
    Jean-Jacques> SG-A and SG-B initially. M must then make sure he will get answers
    Jean-Jacques> destined to A. He may proceed according one of the following ways:

  okay, you've sold me. Can you suggest text to detail this? Are you
suggesting that I simply remove the highlighted (upcase) sentence?
 
    Jean-Jacques> Well anyway, I was only questioning the accuracy of the above
    Jean-Jacques> consideration, but I agree I do hairs splitting here :), and that it
    Jean-Jacques> reaches the frontiers of the charter.

  So, tell me what you'd like to do here...

-