[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on jfk and ikev2 drafts
-----BEGIN PGP SIGNED MESSAGE-----
I had 24 comments about IKEv2, and 8 about JFK.
As JFK has not yet defined how selectors are defined, and I regard this as the
*MAJOR* reason for the marketplace to ask for a replacement for IKEv1, I
consider the JFK draft to be a very rough -00 draft. The amount of text in it
is very small, and would need to double or triple before it could be compared
in any to the IKEv2 draft.
As far as I can tell, neither proposal yet explains to me how to *add* new
traffic to an existing IPsec SA without rekeying it.
{If anyone is wondering if sendmail 8.11 pays attention to certificate
expiry, I just discovered after ten minutes pondering why I can no longer
relay email via my office mail server. It has been 365 days since I set the
thing up. But, it did permit me to connect, just not to relay.}
ikev2-00.txt
1. is the IKE_SA_init_reject forgeable?
page 10 makes me nervous.
actually, all of 2.6 makes me nervous.
2. section 2.4 provides an IKE ping, which is great!
"null query"
3. Delete payloads are a MUST, which is also good.
4. IKE-SA must remain alive for duration of Child-SA. This is good.
(gateways may not drop them)
5. section 2.4.. what about active Distributed Denial of Service attacks?
Other than rate limits, I think that there is nothing we can do.
6. " In IKEv2, like IKEv1, both 8-byte cookies appear in the message, but
in IKEv2 (unlike v1), the value chosen by the message recipient
always appears first in the message. This change eliminates a flaw in
IKEv1, as well as having other advantages (allowing the recipient to
look up the SA based on a small, conveniently chosen value rather
than a 16-byte pseudorandom value.)"
I'm confused by this text.
7. recommend that the list of attacks be made explicit somewhere,
perhaps with reference. Perhaps an appendix.
(this will also make a good test suite)
8. end of section 2.7 (re. DH groups) suggests to me that each end
would benefit from maintaining a per-IP/per-ID database of
information learned from the other end.
9. section 2.8,
" timing of rekeying requests should be dithered (delayed by a random
amount of time)."
Isn't the term here "jitter" appropriate?
10. 2.9: "IKEv2 is more flexible than IKEv1. IKEv2 allows sets of ranges of
both addresses and ports, and allows the Responder to choose a subset
of the requested traffic rather than simply responding "not
acceptable".
This would presumeably permit the initiator to propose:
leftsubnet=mysubnet
rightsubnet=0.0.0.0/0
and the responder could then fill in the subnet that it actually
speaks for. This would permit OE to work more easily for subnets.
The delegation records would also have to exist, but they would not
need to be discovered.
11. comment retracted.
12. a) how big are typical messages for the exchanges?
I am concerned about PMTU issues with IKE packets.
What about an option to use SCTP?
b) will we get some sample exchanges in hex with known keys?
13. 4.1: "A single child-SA negotiation results in two security associations--
one inbound and one outbound. Different Nonces and SPIs for each SA
(one chosen by the Initiator, the other by the Responder) guarantee a
different key for each direction. The SPI chosen by the destination
of the SA and the Nonces (ordered source followed by destination) are
used to derive KEYMAT for that SA."
This suggests tome that the Nx are different, when they are in fact the same.
It is just the SPId that are different, I think.
Should we add something else to guarantee that choice of the same SPI# does not
cause identical keying? I am concerned that SPI# choice is often from a
low-entropy (PRNG) source.
14. section 5:
"The other case in which there is no IKE-SA to protect the information
is when a packet is received with an unknown SPI. In that case the
notification of this condition will be sent in an informational
exchange that is cryptographically unprotected."
I would prefer to have birth certificates introduced here.
I am unclear if an unprotected IKE-SA requires a response, particularly,
an "unknown SPI" message.
15. section 7. I believe that for ESP/UDP/NAT purposes we must insist that
we reverse the port numbers as well as the IP addresses.
16. section 7:
"The Recipient SPI in the header identifies an instance of an IKE
security association. It is therefore possible for a single instance
of IKE to multiplex distinct sessions with multiple peers."
Do you mean "single peer" here?
Are IKE-SAs identified by:
{sourceSPI, destSPI}
or {sourceIP, sourceSPI, destIP, destSPI}
or {sourceIP, sourcePort, sourceSPI, destIP, destPort, destSPI}
17. section 7.1:
"R(eserved) (bits 5-7 of Flags) - These bit MUST be
cleared in messages sent and received messages with
these bits set MUST be rejected."
Note that this in contradiction of the general rule given in
section 2.5, last paragraph on page 9. It should be noted.
18. section 7.1: IV field is new to IKEv2. I would rather that
it was documented identically as for IKEv1, and then the
IV, etc. fields were placed in a seperate section afterward.
19. section 7.2: contrast to IKEv1. I think it is just the addition
of the "Critical" bit in the former reserved field.
20. section 7.3:
"A given transform MAY have one or more Attributes. Attributes are
necessary when the transform can be used in more than one way, as
when an encryption algorithm has a variable key size. The transform
would specify the algorithm and the attribute would specify the key
size. Most transforms do not have attributes."
I would like to discourage use of attributes for key length.
CAST-128 is very different from CAST-256, and a proposal for, say,
CAST-255 would make no sense to most implementations. I think some
implementations may be tempted to provide a slider here, which I
think would make even less sense. The number of permutations of
useable key length is just not that big in my opinion.
21. section 7.3.1
"Protocol-Id (1 byte) - Specifies the protocol identifier
for the current negotiation. During phase 1 negotiation
this field MUST be zero (0). During phase 2 it will be the
protocol of the SA being established as assigned by IANA,
for example, 50 for ESP, 51 for AH, and 108 for IPComp."
Does this present a problem if we wish to negotiate keying materials
for a protocol not at the network layer? e.g. anything running over
TCP or UDP (BGP, HTTP, DNS, etc..)
22. please mark all ID fields which are identical to ones in IKEv1.
(the CERT payload, for instance, appears to be the same)
23. section 7.8 isn't quite clear to me.
I think that one sends an AUTH payload during the second exchange,
signing both the first and second payloads (not including "HDR"?)
that were sent. I assume that AUTH MUST be last?
Is it encrypted?
24. IKEv2 notify payload is not compatible with IKEv1 payload.
If one added the redundant "DOI" field, then I think that an IKEv1
implementation would be able to at least log a notify from an IKEv2.
I don't know if this is worth it.
25. I think that VendorID should always have C=0.
Further, given presence of C bit, a vendorID payload can now be used
to identify whose private-use space is in use as C bit can tell
receiver of message whether or not the information is important or
not.
Suggested text:
The Vendor ID Payload contains a vendor defined constant. The
constant is used by vendors to identify and recognize remote
instances of their implementations. This mechanism allows a vendor
to experiment with new features while maintaining backwards
compatibility.
The Vendor ID payload is both an announcement from the sender of which
space private payload types will come from, and also an announcement of
the sort of private payloads it is willing to accept. The implementation
sending the Vendor ID MAY make assumptions about private payloads that it
may send, provided that all are not marked critical. Upon reception of a
Vendor ID of like stature, a sender may then send critically marked
payloads as as well. Multiple Vendor ID payloads MAY be sent. An
implementation is NOT REQUIRED to send any Vendor ID payload at all.
A Vendor ID payload may be sent as part of any message. Reception of
a familiar Vendor ID payload allows an implementation to make use of
Private USE numbers described throughout this memo-- private
payloads, private exchanges, private notifications, etc. Unfamiliar
Vendor ID's MUST be ignored.
Writers of Internet-Drafts who wish to extend this protocol MUST
define a Vendor ID payload to announce the ability to implement the
extension in the Internet-Draft. It is expected that Internet-Drafts
which gain acceptance and are standardized will be given "magic
numbers" out of the Future Use range by IANA and the requirement to
use a Vendor ID will go away.
26. section 7.13.1.
Please include ICMP as a type that may be negotiated.
Also SCTP.
For ICMP, "port" data corresponds to concatenation of ICMP type and
ICMP code values.
But, why are we including network and transport layer selectors in one
TSI? Why not have proper nesting of protocols?
**** JFK *******
1. "and the complexity of its specification. (This complexity has led
to interoperability problems, so much so that, several years after
its initial adoption by the IETF, there are still completely
non-interoperating implementations.)"
I'm not sure that I buy this statement.
Proof sought. I agree that there are poor programmers.
Are these really *COMPLIANT* implementations?
TCP/IP is widely implemented, yet if you turn on PMTU, there are
multiple networks with web servers which can not be accessed because
they won't let the ICMPs through. All the implementations are
"compliant", but the operators are idiots.
Does this mean that TCP/IP is "complicated" and we should start over?
2. section 2.2
why is g^i and g^r repeated in message 3? Is this so that
r need not store g^i? explained in the text, I see.
Perhaps some more explanation should preceed the details.
I think that in message 3, where you write:
HMAC{HKr}(Ni, Nr, g^i, g^r)
I take this to mean, repeat what you got from message 2, not that
one should compute this. The text makes this clear, but the notation
does not.
3. appears that a single exchange can only be used to generate keys for
a single IPsec SA. This is, I guess, an implicit goal, but I think that
you should tell me this.
4. seciton 2.2: write up is too dense. please use more whitespace and
paragraph breaks.
5. section 2.5 has some LaTeX macros unexpanded.
\mbox{ID}*
6. what is a "ukases" in section 2.5 paragraph 3?
7. section 2.5:
I disagree that the responder is providing the service. This is far
too client/server oriented. There are many cases where a packet may
arrive at a gateway while leaving a "server" location by another route
(multihoming of gateways) which would cause new keying to occur with
the "client".
8. section 2.5, last paragraph.
I reject the rejection of rekeying. Or, I just don't understand.
I'd think that writing:
s/3DES/AES/
s/high speed/very very high speed/
and we have to replace AES with something else. Of course, rekeying
is still supported, but just not conveniently. If this is the point,
then fine.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys
iQCVAwUBPBQ3rIqHRg3pndX9AQGhagQAiWQe6C6nqaxf2dN4YfgzpSDF1WNelQz7
5ozyqBROy7jj5vfV+jBLdhD55DS5kSocAa1Z98me7rVHeCd3ytL9pTlk1jrC3fUs
mwWhPkLfoZIlrTc7BJUpxcWMjEFaPToC7yha7CrDFUmd6Gtuoqp5qu62Y4tuOlfl
mcPhW8g+3U4=
=PvJE
-----END PGP SIGNATURE-----
Follow-Ups: