Re: [IPSECKEY] Security Considerations

[Jean-Jacques Puig <Jean-Jacques.Puig@int-evry.fr>]

Wow, it got huge !

On Tue, May 20, 2003 at 03:32:39PM -0400, Michael Richardson wrote:
> 
> 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].
>

A question regarding the charter ipsec-specific scope: obviously, the
IPSECKEY RR public key is for use with a key management protocol (KMP).
But I came to wonder about what means 'ipsec-specific' ? Does this means
that the KMP belongs to the ipsec protocols suite (this is how I
understand it) or does this means that it is for use for a KMP that is
able to set up ESP or AH SAs ? By the way, do we mean that the DOI of the
key management protocol (KMP) in phase 2 (if applicable) is IPsec ?

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

May be the first thing we should focus on now is to reach for a
consensus about if end to end integrity is REQUIRED or RECOMMANDED.

> 
>    The keying material provided by the IPSECKEY resource record is not
>    sensitive to passive attacks - it 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.
>

Do we really need to speak about IPsec and IKE here ? The RR datas are
expected to be public and as such are implicitly unsensitive to passive
attacks.

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

What about the gateway ? By providing his own gateway (with a suitable
key or with an ipseckey rr for the gateway), wouldn't the attacker
manage to reroute destination packets to him thanks to the tunnel ?
Would this help to set up a MiM ?

> 
>    If the attacker was not able to subsequently mount a second man-in-
>    the-middle attack on the IKE negotiation, then this would result in a
>    denial of service, as the authentication used by IKE would fail.
> 
>    If the attacker was also in a position to perform a man-in-the-middle
>    attack on IKE and IPsec negotiations as well, then it would be a
>    position to compromise the resulting IPsec channel.  Note that an
>    attack must be able to perform active DNS attacks on both sides of
>    the IKE negotiation in order for this to succeed.

I see your point, but is it expected that IKE initiator and responder
will both use IPSECKEY RR ? I think asymetric scenarios may happen
(initiator using IPSECKEY and responder an other scheme).

> 
>    The semantics of when to use this record is outside of the scope of
>    this document.  Any user 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.
> 

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