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

[IPSECKEY] Security Considerations (take 10)



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


The following text is in the -10 document, which I've asked to have
published.  This is the result of many exchanges between Rob, Sam
and I to get thing right.

I have introduced two new headings (4.1.1 and 4.1.2) and moved some text
upwards.

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) [8].

   The IPSECKEY resource record contains information that SHOULD 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. The keying material 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.

|  Any derivative specification that makes use 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.

|  An active attack on the DNS that caused the wrong IP address to be
|  retrieved (via forged address), and therefore the wrong QNAME to be
|  queried would also result in a man-in-the-middle attack. This
|  situation exists independantly of whether or not the IPSECKEY RR is
|  used.

4.1 Active attacks against unsecured IPSECKEY resource records

|  This section deals with active attacks against the DNS. These attacks
|  require that DNS requests and responses be intercepted and changed.
|  DNSSEC is designed to defend against attacks of this kind. This
|  section deals with the situation where DNSSEC is not available. This
|  is not the recommended deployment scenario.

|4.1.1 Active attacks against IPSECKEY keying materials

   The first kind of active attack is when the attacker replaces the
   keying material with either a key under its control or with garbage.

|  The gateway field is either untouched, or is null. The IKE
|  negotiation will therefore occur with the original end-system. For
|  this attack to be successful, the attacker must be able to perform a
|  man-in-the-middle attack on the IKE negotiation. This attack requires
|  that the attacker be able to intercept and modify packets on the
|  forwarding path for the IKE and data packets.

|  If the attacker is not able to perform this man-in-the-middle attack
|  on the IKE negotiation, then this will result in a denial of service,
|  as the IKE negotiation will fail.

   If the attacker is able to both to mount active attacks against DNS
   and is also in a position to perform a man-in-the-middle attack on
   IKE and IPsec negotiations, then the attacker will be in a position
   to compromise the resulting IPsec channel.  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.

|4.1.2 Active attacks against IPSECKEY gateway material

   The second kind of active attack is one in which the attacker
   replaces the the gateway address to point to a node under the
|  attacker's control.  The attacker then either replaces the public key
|  or removes it.  If they were to remove the public key, then they
|  could provide an accurate public key of their own in a second record.

|  This second form creates a simple man-in-the-middle since the
|  attacker can then create a second tunnel to the real destination.
|  Note that, as before, this requires that the attacker also mount an
|  active attack against the responder.

|  Note that the man-in-the-middle can not just forward cleartext
|  packets to the original destination.  While the destination may be
|  willing to speak in the clear, replying to the original sender, the
|  sender will have already created a policy expecting ciphertext. Thus,
|  the attacker will need to intercept traffic in both directions. In
|  some cases, the attacker may be able to accomplish the full intercept
|  by use of Network Addresss/Port Translation (NAT/NAPT) technology.

|  This attack is easier than the first one because the attacker does
|  NOT need to be on the end-to-end forwarding path.  The attacker need
|  only be able to modify DNS replies. This can be done by packet
|  modification, by various kinds of race attacks, or through methods
|  that pollute DNS caches.

|  In cases where the end-to-end integrity of the IPSECKEY RR is
|  suspect, the end client MUST restrict its use of the IPSECKEY RR to
|  cases where the RR owner name matches the content of the gateway
|  field.  As the RR owner name is assumed when the gateway field is
|  null, a null gateway field is considered a match.

|  Thus, any records obtained under unverified conditions (e.g. no
|  DNSSEC, or trusted path to source) that have a non-null gateway field
|  MUST be ignored.

|  This restriction eliminates attacks against the gateway field, which
|  are considered much easier, as the attack does not need to be on the
|  forwarding path.

|  In the case of an IPSECKEY RR with a value of three in its gateway
|  type field, the gateway field contains a domain name. The subsequent
|  query required to translate that name into an IP address or IPSECKEY
|  RR will also be subject to man-in-the-middle attacks. If the
|  end-to-end integrity of this second query is suspect, then the
|  provisions above also apply. The IPSECKEY RR MUST be ignored whenever
|  the resulting gateway does not match the QNAME of the original
|  IPSECKEY RR query.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQI/0IoqHRg3pndX9AQHzIQP6AnlB/TT3QHkOcQrogAKgIrSbIcmAOiuv
oioxl/yQtPqHcDzUjot0AVc1zPNdt6yMhZ2fid46s3rff5jQjj5AqeH25soEieZ3
f6R581l1q0btCdL1vaq3T8Ll3ru/g3lq2WGiLWAKq1kiFRfrAGlujhoEER2n10i+
Ht2j1cN9f6g=
=IV/k
-----END PGP SIGNATURE-----
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.