Subject: [IPSECKEY] Hugh Daniel: [Design] Security Considerations for IPSECKEY

From: Michael Richardson <[email-masked]>
Date: Tue, 20 May 2003 14:00:21 -0400

From: Hugh Daniel <[email-masked]>
Subject: [Design] Security Considerations for IPSECKEY

-----BEGIN PGP SIGNED MESSAGE-----

  A debate has arisen over the IPSECKEY draft "Security Considerations"
 section that is blocking it's forward progress.  Let me take a stab
 at clearing up the issues a bit.

  There are two things that I think need to be clarified, first the
the user threat model vs. integrity/authentication and second is the
reach of any such integrity/authentication.

  So to the first issue.  In the case of the current (non DNSsec) DNS
system the IPSECKEY RR is very useful to any Internet user who's
security "threat model" does not need to protect against "active
attacks" such as Man-in-the-Middle (MitM).

  To protect against such active attacks one needs both verify and
authenticate the entirety of the IPSECKEY RR (and many other RR's with
out with the IPSECKEY RR is useless).

  The choice between these two usage models must be left up to the
users and system/network administrators, but that a choice is being
made by _someone_ needs to be clearly defined, maybe here.

  I feel that the IPSECKEY RR is clearly useful even in a non-DNSsec
world where it provides protection against all forms of "passive
attack".

  To explain why an un-verified/un-authenticated IPSECKEY RR is useful
think about the difference between what security geeks call a "passive
attack" vs. an "active attack".  In an "active attack" the attacker
needs to be in a position to alter the data flow (in this case the
IPSECKEY RR) which can be hard and prone to detection.  In a "passive
attack" no data or meta data is changed, just "snooped", but the user
can still be harmed (identity theft is an example).

  Thus having even an un-verified/un-authenticated IPSECKEY RR can
help provide critical network security.

  In our case with IPsec we have even better protection in that unless
the malfeasant is in a position to also mount a MitM attack any
altered IPSECKEY RR data will be detected by ISAKMP/IKE and be
rejected with NO security threat (wrong key, no SA's get created, no
user data is moved), just a standard DoS as one might get with any
sort of DNS poisoning.

  The second issue of the 'reach' of the integrity/authentication is
what I think Mr. Richardson was trying to address in the -01 draft and
likely needs to be made more clear.

  If the users (or system/network admins) "threat model" policy
causes the IPSECKEY RR (and other RR's) to be integrity/authentication
checked then the check it's self has to be securely delivered to the
end user/program.

  In the current Internet it is quite possible that network designers
will try to create networks where DNSsec caching and/or validation
will happen on hosts that are across un-secured local LAN's from the
end user/program.  Such networks are fundamentally only as secure as
the first issue case (raw DNS that protects only against passive
attacks).

  I read the current wording as a warning against such non End-to-End
designs, yet it is clear that the wording needs to be improved.

  Lastly, with the IPSECKEY RR the WG is providing a critical tool to
link DNS information with bulk TCP/IP data transit, yet such a linkage
might have different meanings to different users depending on how
their systems use IPSECKEY along with other protocols (DNSsec, IPsec
etc.).  

  Thus the current draft statement that "The semantics of this record
is outside of the scope of this document,"... is very true, though
possibly in need of word smithing.

  I would like to note that we are all "security geeks" here and will
need to work hard at not making the "Security Considerations" section
longer then the actual document...if not longer then the IPsec RFC's
in total!

		||ugh Daniel
		[email-masked]

			Systems Testing & Project mis-Management
			The Linux FreeS/WAN Project
			http://www.freeswan.org

_______________________________________________
Design mailing list
[email-masked]
http://lists.freeswan.org/mailman/listinfo/design

-
This is the [email-masked] list.
Email to [email-masked] to be removed.