[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
weakness in IKE/DOI specs
No range is specified for the SA Life Duration Attribute Type in the
DOI (RFC 2407). Nor is this specified in the latest revised IKE
Internet-Draft (draft-ieft-ipsec-ike-01.txt).
The physical limit set by the coding of a Data Attribute in ISAKMP
(RFC 2408, Section 3.3) is (2^(65536*8))-1 kilobytes or seconds. This
is a perposterously large limit, one that nobody would ever want to
implement. (Using bignums for byte counters?) This is a big enough
number to measure the life of the universe in seconds, and then a lot
more!
Moreover, as a security feature, we know that you really don't want
large lifetimes anyway. Too much ciphertext on too little key.
I think it is perfectly appropriate to limit these to 32 bits, with
the range being 0 to (2^32)-1. I don't think there is any sensible
justification to allow 64 bit values, that's just too long a
lifetime.
Also, are there any restrictions on the value of an Attribute Length?
Is 1 a legal? Or must you use the short form when Attribute Length
would be less than 3? Also, is an attribute length of 3 legal for a
lifetime? I could want a lifetime of 128 Kbytes, I could choose to
code that as "00 02 00 03 01 00 00", rather than the far more sensible
"00 02 00 04 00 01 00 00". Can ANYONE parse that 3 byte lifetime? I
doubt it! Should we allow it? I don't think so!
I think that the only allowable encodings for SA Duration should be:
80 02 xx xx (xxxx is lifetime < 65536)
and
00 02 00 04
yy yy yy yy (yyyyyyyy is lifetime >= 65536 and
< 4294967296)
Interestingly, our own code sends any lifetime greater than 255 in
the long format. Odd. It actively pukes if it receives a long format
with a length other than 4.
This issue partly comes up because we've coded these as Unsigned32 in
the MIB, but there's nothing in the protocol definitions that assures
us that Unsigned32 is sufficient.