summaryrefslogtreecommitdiff
path: root/keyexchange/isakmpd-20041012/QUESTIONS
diff options
context:
space:
mode:
authorOthmar Gsenger <otti@anytun.org>2008-05-25 09:50:42 +0000
committerOthmar Gsenger <otti@anytun.org>2008-05-25 09:50:42 +0000
commit71da41451212389bea25d67bc5da696b6d194bff (patch)
treea3b20decbd8bc9e47640af5fa4b39f731477955a /keyexchange/isakmpd-20041012/QUESTIONS
parentimproved presentation again (diff)
moved keyexchange to http://anytun.org/svn/keyexchange
Diffstat (limited to 'keyexchange/isakmpd-20041012/QUESTIONS')
-rw-r--r--keyexchange/isakmpd-20041012/QUESTIONS34
1 files changed, 0 insertions, 34 deletions
diff --git a/keyexchange/isakmpd-20041012/QUESTIONS b/keyexchange/isakmpd-20041012/QUESTIONS
deleted file mode 100644
index 91225cc..0000000
--- a/keyexchange/isakmpd-20041012/QUESTIONS
+++ /dev/null
@@ -1,34 +0,0 @@
-$OpenBSD: QUESTIONS,v 1.5 2003/11/05 12:31:21 jmc Exp $
-$EOM: QUESTIONS,v 1.12 1998/10/11 17:11:06 niklas Exp $
-
-Does the spec limit the count of SA payloads in a message? Where if so?
-[ Only the specific IKE main mode does. In the IKE spec.]
-
-The message ID field of the header, can it be considered a SA identifier
-if used together with the cookiepair? [Yes, it is meant to be that]
-
-DOI 0, what protocols are defined for it? Where?
-
-Isn't this a potential DOS attack:
-Hostile user listens for ISAKMP traffic, and then extracts cookiepairs
-and message IDs which he uses to flood any of the peers with spoofed
-packets pretending to be the other one. Most probably these packets will
-result in error notifications which potentially result in SA tear-down?
-Maybe should notifications never be issued for erroneous packets which
-cannot be authenticated? Or should we not tear down SAs as results of
-notifications?
-
-Certicom claims to hold licenses for Elliptic Curve Cryptography? Does this
-concern us? See: http://grouper.ieee.org/groups/1363/P1363/patents.html
-
-Main mode when using public key encryption authentication does not look
-like an identity protection exchange to me. Must I really get rid of
-the generic ISAKMP payload presense tests?
-
-IV generation is not described precisely in Appendix B of -oakley-08.txt:
-'Subsequent messages MUST use the last CBC encryption block from the previous
-message as their IV'. This probably means that we take the new IV from the
-last encrypted block of the last message we sent. The SSH testing site uses
-the last block from the last message they received. This is probably not
-what was meant and should be clarified on ipsec@tis.com.
-[ From what we have gathered this is what is meant. ]