[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IPSECKEY] Security Considerations
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.