[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Subject: Re: Merged IKE - suites and negotiation
Black_David@emc.com writes:
> > For instance, although I still prefer
> > suites, I'm not exactly sure how the ESP/AH
> > extended sequence numbers are supposed to work, now that we're not
> > individually negotiating features. I guess it will be defined as part
> > of the suite (not only what cryptographic algorithms are used, but
> > whether ESP/AH extended sequence numbers will be used).
I do not prefer suites. I think they will have way too much dimensions
to be useful. I.e things we currently store in the SA information and
which would appear in the suite (or somewhere else) (for the IKE).
1) authentication algorihtm
- rsa signatures, dsa signatures?, pre-shared keys?
2) encryption algorithm
- 3des, aes-128, aes-192?, aes-256?
3) hash/prf algorithm
- sha1, md5?, sha2-256?, sha2-384?, sha2-512?
4) Diffie-Hellman group
- group 2, group 5, ec-groups?, bigger (2048, 3096, 4096, 6144,
8192 bit) groups
5) Window size fof IKE
- 1, 10? ???
I am ignoring here variable length keys in ciphers and groups defined
by the parameters.
For the IPsec there would be:
1) encryption algorithm for the ESP
- 3DES, AES, NULL
2) authentication algorithm for the ESP
- no auth, MD5, SHA
3) authentication algorithm for the AH
- no AH, MD5, SHA
4) IPComp algorithm
- Deflate, LZS?, OUI?
5) Diffie-Hellman group for PFS (if we do support PFS)
- group 2, group 5, ec-groups?, bigger (2048, 3072, 4096, 6144,
8192 bit) groups
6) Tunnel / transport / UDP-tunnel / UDP-transport
- Tunnel mode / transport mode and NAT-T udp encapsulations
7) Use of extended sequence numbers
- on/off
8) ECN
...
Again ignoring variable length keys in ciphers, key rounds etc.
> What about viewing suites as one component of a multi-component
> negotiation, where each component is negotiated independently
> as in IKEv2?
Then you need code for both, i.e if suites do not define everything
then it is easier to do everything ala carte as you already are
parsing the packet.
> I'm concerned about things like the extended
> sequence number and options related to transport processing -
> there's currently an SA attribute related to ECN, and I can't
> be sure that another won't arise as part of allowing outer to
> inner DSCP (Differentiated Services Code Point) propagation
> at tunnel egress. These don't feel like natural parts of a
> crypto suite, and in essence demanding that everything be
> part of an all-encompassing suite only works in 20/20 hindsight.
True.
> I got bit by the analogous structure of IKEv1 proposals in
> the ECN work; if one actually tries to use the ECN Tunnel SA
> attribute, it can easily double the number of proposals that
> need to be offered. I'd sure like to see IKEv2 not repeat
With IKEv2 proposal with ala carte negotiation that would not
happened, as each of the parameters was negotiated separately. I.e you
would negotitiate ecn on or off and it would not affect your cipher
selection.
> this problem or make it worse. Having the humility to admit
> that we might not have anticipated everything that ought to
> be part of IKE would be a good thing.
I think having the IKEv2 style ala carte negotiation is easier to code
and implement, and there will be fewer bugs than in the suite version.
Also I consider that easier to test also, as I can test the code piece
by piece. I first start testing all ciphers, without modifying
anything else. If that passes then I test all hashes etc... For the
software implementations that will usually cover almost everything.
And it is quite easy to do test script that will actually test all
possible combinations.
For suites I would always need to test all possible combinations, and
with test script that is fine, but for example in the interop testing
event it is not ok. The most common place to have bugs there is the
table that maps the suite numbers to actual algorithms that are used.
There have been such bugs in TLS implementations, and I think there
are still such bugs in TLS implementations that are not yet detected,
as nobody is using that suite yet...
For most of the interop events we have been testing well selected
combinations of ciphers, like DES-SHA1-group-2, 3DES-MD5-group-5,
AES-SHA1-group1 (to test bigger block size, and to test key expansion
from short secret to longer key) etc.
Usually those test "suites" would not have been very usefull in
practice (like tunnel-with-external-ipv4 esp-blowfish-sha1
ipv6-packet-inside-tunnel ah-md5-transport ipcomp or similar). This
would mean that we cannot do similar test as much as possible with
very few tests with suites as there would not be such test suites
defined.
I am quite sure we will end up with too much negotiable parameters
that we will need some kind of ala carte negotiation for those, and if
so why not use that for also basic parameters too.
In IKEv1 the ala carte negotiation was little too extreme, because
there you needed to list all "suites" you would accept, i.e if you
wanted to support 3des, or aes and md5 or sha1, you end up having 4
transforms. With IKEv2 you would offer cipher 3des or aes, and hash
md5 or sha1 and the responder will pick for each list anything he
likes. This comes especially handly if you don't really care about the
group and say that groups 2, 5, or 2048, 3072 and 4096-bit groups is
acceptable. For IKEv1 it would multiple the transform count from 4 to
20. For IKEv2 with ala carte it would simply add 4 more group
transforms.
It makes the SA payloads much smaller and easier to understand in
common case.
So I would very much favor the current IKEv2 ala carte method than
suites.
--
kivinen@ssh.fi
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/