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

Re: [IPSECKEY] Security Considerations (pass 2)



On Tue, May 20, 2003 at 07:32:37PM -0400, Michael Richardson wrote:
> -----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

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

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

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.

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

--
Jean-Jacques Puig
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.