[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IPSECKEY] Security Considerations (pass 2)
At Tue, 20 May 2003 19:32:37 -0400, Michael Richardson wrote:
>
> 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.
> 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-
s/were/is/
s/subsequently mount a second/mount a subsequent/
> 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.
s/would/will/g
> 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
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/
> 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
s/is when/is one in which/
> 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
s/can/can then/
s/as well, or remove it -/or remove it, thus/
> address.
>
> 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,/
> 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
s/only/just/
> 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.
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/
> 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.
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.
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.