[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suites vs a-la-carte



I agree that suites seem overwhelming when considered from this
perspective. However, there is another way to look at this. Before going
into that, I should point out that we don't have to support every
esoteric combination anyone could dream up. If we provide numbers for
all mainstream combinations and then provide for vendor IDs and private
numbers, folks wanting unusual combinations can define them privately. 
It's been my experience that most implementations don't make use of more
than a few combinations in practice.

Instead of thinking in terms of one number which encodes everything, we
could view it in terms of phase 1 suites and phase 2 general parameters
*and* suites. This does require support for a la carte selection of
phase 2 general parameters, but that doesn't look so horrible at first
glance (there aren't that many of them).

Phase 1 suites are composed of crypto-hash-auth-dhgroup. Phase 2 general
parameters include tunnel/transport/udp-tunnel/extended-seq/ecn (we can
deprecate key pfs, and negotiate new p1 instead). Phase 2 suites
comprise a bundle of one or more security protocols and their attrs. If
we deprecate AH, this reduces the space somewhat, but even if we don't,
it doesn't add all that much. Here's an example encoding:
 
Phase 1 suites: crypto-hash-auth-dhgroup

crypto
------
3DES
AES_CBC
AES_CTR

hash
-----
MD5
SHA1

auth
-----
RSA
PSK
(deprecate DSS, since nobody but redcreek ever admitted to implementing
it)

DHGROUP
------
2
5
(deprecate 1 since it's weak, ignore 3,4 since they are not widely used;
folks wanting private groups define vendor-ids and private suite
numbers)

Phase 1 Suites:
----------------
3DES-MD5-RSA-2
3DES-MD5-RSA-5
3DES-MD5-PSK-2
3DES-MD5-PSK-5
3DES-SHA1-RSA-2
3DES-SHA1-RSA-5
3DES-SHA1-PSK-2
3DES-SHA1-PSK-5

AES_CBC-MD5-RSA-2
AES_CBC-MD5-RSA-5
AES_CBC-MD5-PSK-2
AES_CBC-MD5-PSK-5
AES_CBC-SHA1-RSA-2
AES_CBC-SHA1-RSA-5
AES_CBC-SHA1-PSK-2
AES_CBC-SHA1-PSK-5

AES_CTR-MD5-RSA-2
AES_CTR-MD5-RSA-5
AES_CTR-MD5-PSK-2
AES_CTR-MD5-PSK-5
AES_CTR-SHA1-RSA-2
AES_CTR-SHA1-RSA-5
AES_CTR-SHA1-PSK-2
AES_CTR-SHA1-PSK-5


Phase 2 suites: [alg-1:params|alg-2:params...|alg-n:params]

general parms: tunnel/transport/udp-tunnel/extended-seq/ecn
(deprecate key pfs - negotiate new p1 instead)

Esp: crypto-integrity

E1: ESP-3DES-SHA1
E2: ESP-3DES-MD5
E3: ESP-AES_CBC-SHA1
E4: ESP-AES_CBC-MD5
E5: ESP-AES_CTR-SHA1
E6: ESP-AES_CTR-MD5
E7: ESP-NONE-SHA1
E8: ESP-NONE-MD5
(crypto with no integrity is not allowed)

AH: (deprecate)

IPCOMP: compress-alg
I1: DEFLATE
I2: OUI
I3: LZS


Suites definitions (alg combinations):
E1
E2
E3
E4
E5
E6
E1-I1
E2-I1
E3-I1
E4-I1
E5-I1
E6-I1
E1-I2
E2-I2
E3-I2
E4-I2
E5-I2
E6-I2
E1-I3
E2-I3
E3-I3
E4-I3
E5-I3
E6-I3
I1
I2
I3

I admit that listing and numbering these is somewhat tedious, but it's
certainly do-able, and doesn't explode combinatorially as long as we
don't go nuts and try to support everything.

Scott


Tero Kivinen wrote:
> 
> I didn't receive any comments of my previous mail about this issue, I
> think it was too long or something.
> 
> Anyways I think the IKEv2 has way too many dimensions to negotiate
> for suite style negotiation. For IKE SA creation there is 5 different
> dimensions, and some of them are open ended numbers. For IPsec SA we
> have about 6 and then at least 2 new extensions.
> 
> We cannot realisticly encode all that informatin to one single number.
> 
> This means that we propably need to have some of those parameters
> negotiated as a-la-carte style negotiation (Diffie-Hellman group,
> window size, extension options in IPsec (extended sequence numbers,
> ECN) etc). If we are going to add the a-la-carte negotiation then I
> think it is better to everything in same way not to mix them, thus use
> the a-la-carte completely.
> 
> We can have gui-suites for the commonly used parameters, but in that
> case too we might want to include all information to those numbers
> (like window size).
> 
> Just for the reminder here is the list of things we need to encode as
> one single number in IKE SA:
> 
> 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? ???
> 
> And for the IPsec SA 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
> --
> kivinen@ssh.fi
> SSH Communications Security                  http://www.ssh.fi/
> SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/