Subject: Re: [IPSECKEY] Security Considerations

From: Rob Austein <[email-masked]>
Date: Tue, 20 May 2003 18:40:48 -0400

At Tue, 20 May 2003 17:51:22 -0400, Michael Richardson wrote:
> >>>>> "Jean-Jacques" == Jean-Jacques Puig <[email-masked]> writes:
>
>     >> 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.
> 
>     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.

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

---

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

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

I've restructured it a bit. Comments welcome.

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

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.

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

   If the attacker were not able to subsequently mount a second man-in-
   the-middle attack on the IKE negotiation after replacing the public
   key, then this would result in a denial of service, as the
   authenticator used by IKE would fail.

   If the attacker were able to mount both active attacks against DNS,
   and in a position to perform a man-in-the-middle attack on IKE and
   IPsec negotiations, then the attacker would 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.

   The second kind of active attack is when the attacker replaces the
   the gateway address to point to a node under the attacker's control.
   The attacker can either replace the public key as well, or remove it
   - providing an IPSECKEY record of its own to match the gateway
   address.

   This later form creates a simple man-in-the-middle.  The attacker
   could 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 only 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 would have already created a policy expecting ciphertext.
   Thus, the need for attacker to intercept traffic from both sides.

   A protocol which permits the gateway field to delegate to a different
   host MAY want to restrict this feature when end-to-end integrity is
   not available.

Richardson             Expires September 30, 2003              [Page 10]

Internet-Draft                   ipsecrr                      April 2003

5. IANA Considerations

   IANA is asked to assign a resource record type number from the normal
   resource record number space.

   The algorithm field does not require any IANA action, as it is
   inherited from DNS KEY algorithm values.

Richardson             Expires September 30, 2003              [Page 11]

Internet-Draft                   ipsecrr                      April 2003

6. Acknowledgments

   My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, and Olafur
   Gurmundsson who reviewed this document carefully.  Additional thanks
   to Olafur Gurmundsson for a reference implementation.

Richardson             Expires September 30, 2003              [Page 12]

Internet-Draft                   ipsecrr                      April 2003

Normative references

   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
        13, RFC 1034, November 1987.

   [2]  Mockapetris, P., "Domain names - implementation and
        specification", STD 13, RFC 1035, November 1987.

   [3]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
        9, RFC 2026, October 1996.

   [4]  Eastlake, D. and C. Kaufman, "Domain Name System Security
        Extensions", RFC 2065, January 1997.

Richardson             Expires September 30, 2003              [Page 13]

Internet-Draft                   ipsecrr                      April 2003

Non-normative references

   [5]   Thomson, S. and C. Huitema, "DNS Extensions to support IP
         version 6", RFC 1886, December 1995.

   [6]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [7]   Piper, D., "The Internet IP Security Domain of Interpretation
         for ISAKMP", RFC 2407, November 1998.

   [8]   Eastlake, D., "Domain Name System Security Extensions", RFC
         2535, March 1999.

   [9]   Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
         (DNS)", RFC 2536, March 1999.

   [10]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
         System (DNS)", RFC 3110, May 2001.

   [11]  Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
         Record (RR)", RFC 3445, December 2002.

Author's Address

   Michael C. Richardson
   Sandelman Software Works
   470 Dawson Avenue
   Ottawa, ON  K1Z 5V7
   CA

   EMail: [email-masked]
   URI:   http://www.sandelman.ottawa.on.ca/

Richardson             Expires September 30, 2003              [Page 14]

Internet-Draft                   ipsecrr                      April 2003

Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Richardson             Expires September 30, 2003              [Page 15]


-

---

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

> I've restructured it a bit. Comments welcome.

Content looks good.

Nits (many of which are really just a single tense agreement problem
that appears in many places throughout the text), plus one point
that's a bit unclear, at the very end.

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

s/were/is/
s/subsequently mount a second/mount a subsequent/

>    authenticator used by IKE would fail.

s/would/will/g

>    and in a position to perform a man-in-the-middle attack on IKE and

s/were able to mount both/is able both to mount/
s/DNS, and in/DNS and is also in/

>    IPsec negotiations, then the attacker would be in a position to

s/would/will/

>    The second kind of active attack is when the attacker replaces the

s/is when/is one in which/

>    - providing an IPSECKEY record of its own to match the gateway

s/can/can then/
s/as well, or remove it -/or remove it, thus/

>    This later form creates a simple man-in-the-middle.  The attacker

s/man-in-the-middle.  The/man-in-the-middle attack, since the/

>    could create a second tunnel to the real destination.  Note that as

s/could/can then/
s/that/that,/

>    Note that the man-in-the-middle can not only forward cleartext

s/only/just/

>    sender would have already created a policy expecting ciphertext.

s/would/will/

>    Thus, the need for attacker to intercept traffic from both sides.

s/Thus, the need for attacker/Thus, the attacker will need/

>    host MAY want to restrict this feature when end-to-end integrity is

Er, from what is the gateway field different?  The RR owner name?  How
should this test be applied when:

a) the RR owner name is an encoded address (reverse tree) and the
   gateway field is a DNS name, or

b) the RR owner name is a "normal" DNS name and the gateway field is
   one of the address forms?

Bit of a slippery slope.
-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 May 2003 11:45:36 -0400

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

    Rob> Content looks good.

    Rob> Nits (many of which are really just a single tense agreement problem
    Rob> that appears in many places throughout the text), plus one point

  Thanks for all of this. I certainly can fix it myself, but never on the
same day as writing the original.

    >> host MAY want to restrict this feature when end-to-end integrity is

    Rob> Er, from what is the gateway field different?  The RR owner name?  How
    Rob> should this test be applied when:

    Rob> a) the RR owner name is an encoded address (reverse tree) and the
    Rob>    gateway field is a DNS name, or

    Rob> b) the RR owner name is a "normal" DNS name and the gateway field is
    Rob>    one of the address forms?

    Rob> Bit of a slippery slope.

  Without integrity protection, one *might* want to permit only the situation
where "No gateway is present", or IP an IP address is present that it is ==
to the thing that one looked up originally. The first example is shows a node
that has delegate to self.

]       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"); [

-

---

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

>    Note that the man-in-the-middle can not only forward cleartext

(I think both are corrects, but the second may be more 'academic':)
s/can not/cannot/

>    Thus, the need for attacker to intercept traffic from both sides.

Though it is not usefull to mention it in the draft, I think
the attacker may achieve easily this interception:
1) Attacker provides a wrong IPSECKEY RR with it's own gateway through
DNS cache poisonning.
2) Initiator establishes tunnel with attacker's gateway.
3) Initiator sends packets to Destination through tunnel.
4) Attacker masquerades source address of packets coming through the
tunnel, and forwards them to Destination.
5) Destination answers to the masqueraded address (the attacker)
6) Attacker masquerades destination address of packets coming from
Destination, and forwards them through the tunnel, etc.
Attackers main difficulty is then to deal with transport checksums and
application datas containing endpoint addresses or names.

--
Jean-Jacques Puig
-

---

From: Rob Austein <[email-masked]>
Date: Thu, 22 May 2003 14:49:39 -0400

[Sorry for the delay, took yesterday off]

> that has delegate to self.

So perhaps something like the following would do (keyboarded, might
need wordsmithing):

  Note that the danger here only applies to cases where the gateway
  field of the IPSECKEY RR indicates a different entity than the owner
  name of the IPSECKEY RR.  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.

[*] Open MAY/SHOULD/MUST question here here.  I've written it as MUST
because that's my own preference, but others may disagree.  Reasoning,
such as it is: the context of this whole subsection assumes an
environment in which we are worried about MitM attacks, so I think
we've already handled Hugh's "passive attacks only" context elsewhere,
and I suspect that anything weaker than a MUST in this context here is
going to cause delays during IETF Last Call, etcetera.

If anybone thinks that MUST is wrong here, please speak up.
-
This is the [email-masked] list.
Email to [email-masked] to be removed.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 22 May 2003 15:43:15 -0400

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

>>>>> "Rob" == Rob Austein <[email-masked]> writes:
    Rob> So perhaps something like the following would do (keyboarded, might
    Rob> need wordsmithing):

    Rob>   Note that the danger here only applies to cases where the gateway
    Rob>   field of the IPSECKEY RR indicates a different entity than the owner
    Rob>   name of the IPSECKEY RR.  In cases where the end-to-end integrity of
    Rob>   the IPSECKEY RR is suspect, the end client MUST[*] restrict its use
    Rob>   of the IPSECKEY RR to cases where the RR owner name matches the
    Rob>   content of the gateway field.

  I don't find anything wrong with your text, and I agree about the MUST.

  The current OE document, already says, for instance:

3.2.4.1 Restriction on unauthenticated TXT delegation records

   An implementation SHOULD also provide an additional administrative
   control on delegation records and DNSSEC.  This control would apply
   to delegation records (the TXT records in the reverse-map) that are
   not protected by DNSSEC.  Records of this type are only permitted to
   delegate to their own address as a gateway.  When this option is
   enabled, an active attack on DNS will be unable to redirect packets
   to other than the original destination.

---

From: Jean-Jacques Puig <[email-masked]>
Date: Fri, 23 May 2003 12:38:27 +0200

>   I don't find anything wrong with your text, and I agree about the MUST.

Question: what do you mean by: "In cases where the end-to-end integrity
of the IPSECKEY RR is suspect" ?

	Do you mean:
		a) Implementation detected (how ?) or expects with a
		reasonnable probability that an active attack is under way. Then I
		agree the end client MUST restrict the use of the record.
	or:
		b) When there is no end-to-end integrity, (or when a gateway cannot
		know surely about that), the end client MUST restrict the use of
		the record.

	In case b), the end client does not know whether he is the victim of
	an active attack or not. Therefore, our choice here will affect
	implementations behaviour in networks in which only passive attacks

> going to cause delays during IETF Last Call, etcetera.

I would like to be sure that Mr Daniel has no further arguments about
the interest of the gateway field to be different from the RR owner in
the "passive attacks only context".

In the context of active attack, I agree on a MUST, but how the
implementation would know in which context it is ? Is it a choice from
the administrator ?

I think we can state it this way:

In an environment in which only passive attacks are likely to happen,
both key information and gateway option are to be trusted, and no specific
end-to-end integrity protection is required.

In an environment in which active attacks are likely to happen, both key
information and gateway option are extremely vulnerable without the
use of end-to-end integrity protection. Thus, in such an environment,
the dns client MUST refuse any gateway field different from the RR owner
name. Note that this implies coherence of types between RR owner name
and gateway field (both IPv4 or both FQDN or both IPv6 etc), thus the
use of self "." is recommanded for ease of use.

Clients using IPSECKEY RR MAY provide a way to choose that no protection
against active attacks is required. In this latter case, the client
MAY restrict its use of the IPSECKEY RR to cases where the RR owner
name matches.

I'm really sorry to mess around with these problems of MAY/SHOULD/MUST,
but I fear current statements let opened too many questions or may lead
to restrict too much.

---

From: Rob Austein <[email-masked]>
Date: Sun, 25 May 2003 15:48:37 -0400

> implementation would know in which context it is ? Is it a choice from

In my opinion, the answer to this is "yes" (that is, I think that the
decision on whether to worry about active attacks is administrative,
and takes place on the client side).  It might be appropriate for us
to say that the default (for clueless administrators) must be to worry
about active attacks, but I think that Hugh has made a decent case for
why an implementor might chose to provide a way for consenting adults
to chose not to worry about active attacks.

> use of self "." is recommanded for ease of use.

Yeah, I was wondering if I should have punted the stuff about the RR
owner name matching the gateway field and just said that a client
which has to worry about active attacks on the DNS data MUST NOT trust
IPSECKEY records with a non-zero gateway type field.
-
This is the [email-masked] list.
Email to [email-masked] to be removed.

---

From: Rob Austein <[email-masked]>
Date: Mon, 26 May 2003 11:22:36 -0400

At Mon, 26 May 2003 10:20:45 +0200, Jean-Jacques Puig wrote:
> 
> That's good question. Besides, on the server side, section 3.1 mandates:
> 
> If no gateway is to be indicated, then the gateway type field MUST be
> zero, and the gateway type MUST be "."
> 
> BTW, s/gateway type/gateway field/ ?

The second one, yes ('the gateway type MUST be "."'), good catch.
> 
> Is there a peticular difference between the following 2 cases ?
> 
> - No gateway (type=0 gateway=".")
> - The gateway is the same as the RR owner (ex: type=1
>   gateway=192.0.2.38)
> 
> I would take type=0 as a clue that the host will accept transport mode
> SA, and (type != 0 && address == RR_owner) as a clue that the host will
> take only tunnel mode proposals. Is it the original intent ?

Michael will have to speak to intent, but I didn't read it that way.
I read the two cases as semantically equivalent, and had assumed that
the choice of tunnel vs transport mode was something to be negotiated
by the parties involved.

We probably need a sentence in the draft to clarify this, one way or
the other.
-
This is the [email-masked] list.
Email to [email-masked] to be removed.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 May 2003 13:33:25 -0400

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

    >> BTW, s/gateway type/gateway field/ ?

    Rob> The second one, yes ('the gateway type MUST be "."'), good catch.

  Thank you.

    >> take only tunnel mode proposals. Is it the original intent ?

    Rob> Michael will have to speak to intent, but I didn't read it that way.
    Rob> I read the two cases as semantically equivalent, and had assumed that
    Rob> the choice of tunnel vs transport mode was something to be negotiated
    Rob> by the parties involved.

  No intent is implied by this document.
  My opinion is that you would need to write a use-case document that
explains how to you are using the record.

-

---

From: Jean-Jacques Puig <[email-masked]>
Date: Mon, 26 May 2003 10:20:45 +0200

---

From: Jean-Jacques Puig <[email-masked]>
Date: Tue, 27 May 2003 09:14:54 +0200

> explains how to you are using the record.

	Right. Then current consideration about RR owner name matching
content of the gateway field sounds both precise enough and not too
restrictive. Looks fine for me.

--
Jean-Jacques
-