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