[prev in list] [next in list] [prev in thread] [next in thread]
List: ipsec
Subject: Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02
From: Tero Kivinen <kivinen () iki ! fi>
Date: 2018-10-31 23:03:51
Message-ID: 23514.13527.860102.126373 () fireball ! acr ! fi
[Download RAW message or body]
Scott Fluhrer (sfluhrer) writes:
> My issue with this general idea is backwards compatibility; if we
> issue a transform of type 5 to an old IKEv2 system, it may reject
> the entire exchange with an "unrecognized transform type" error (and
> yes, there are real systems that behave this way).
That implementation is broken, and needs to be fixed.
> And, it could be argued that such an IKEv2 implementation would be
> compliant; section 3.3.3 of RFC7296 would appear to forbid any
> transform types other than 1-4 in an IKE negotiation.
That is not true. Section 3.3.3 lists mandatory types, and those
optional types, which are included in that RFC. It does NOT list any
of the future optional types.
In section 3.3.6 this is explained very clearly:
If the responder receives a proposal that contains a Transform Type
it does not understand, or a proposal that is missing a mandatory
Transform Type, it MUST consider this proposal unacceptable; however,
other proposals in the same SA payload are processed as usual.
Similarly, if the responder receives a transform that it does not
understand, or one that contains a Transform Attribute it does not
understand, it MUST consider this transform unacceptable; other
transforms with the same Transform Type are processed as usual. This
allows new Transform Types and Transform Attributes to be defined in
the future.
I.e., the intention is that if there is transform type you do not
understand you skip whole proposal, but STILL PROCESS rest of the
proposals normally, i.e., this allows backward compatiblity.
I.e., if we have SA payload:
SA Payload
|
+--- Proposal #1 ( Proto ID = IKE(1), SPI size = 0,
| | 14 transforms)
| |
| +-- Transform ENCR ( Name = ENCR_AES_CBC )
| | +-- Attribute ( Key Length = 128 )
| +-- Transform ENCR ( Name = ENCR_AES_CBC )
| | +-- Attribute ( Key Length = 192 )
| +-- Transform ENCR ( Name = ENCR_AES_CBC )
| | +-- Attribute ( Key Length = 256 )
| +-- Transform PRF ( Name = PRF_HMAC_SHA2_256 )
| +-- Transform PRF ( Name = PRF_HMAC_SHA2_384 )
| +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 )
| +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_256_128 )
| +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_384_192 )
| +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 )
| +-- Transform D-H ( Name = 8192-bit MODP Group )
| +-- Transform D-H ( Name = Curve25519 )
| +-- Transform D-H ( Name = Curve448 )
| +-- Transform QSKE1 ( Name = Foobar )
| +-- Transform QSKE1 ( Name = Zappa )
|
+--- Proposal #2 ( Proto ID = IKE(1), SPI size = 0,
| | 14 transforms)
| |
| +-- Transform ENCR ( Name = ENCR_AES_CBC )
| | +-- Attribute ( Key Length = 128 )
| +-- Transform ENCR ( Name = ENCR_AES_CBC )
| | +-- Attribute ( Key Length = 192 )
| +-- Transform ENCR ( Name = ENCR_AES_CBC )
| | +-- Attribute ( Key Length = 256 )
| +-- Transform PRF ( Name = PRF_HMAC_SHA2_256 )
| +-- Transform PRF ( Name = PRF_HMAC_SHA2_384 )
| +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 )
| +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_256_128 )
| +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_384_192 )
| +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 )
| +-- Transform D-H ( Name = 8192-bit MODP Group )
| +-- Transform D-H ( Name = Curve25519 )
| +-- Transform D-H ( Name = Curve448 )
| +-- Transform QSKE1 ( Name = Foobar )
| +-- Transform QSKE2 ( Name = Zappa )
|
+--- Proposal #3 ( Proto ID = IKE(1), SPI size = 0,
| 12 transforms)
|
+-- Transform ENCR ( Name = ENCR_AES_CBC )
| +-- Attribute ( Key Length = 128 )
+-- Transform ENCR ( Name = ENCR_AES_CBC )
| +-- Attribute ( Key Length = 192 )
+-- Transform ENCR ( Name = ENCR_AES_CBC )
| +-- Attribute ( Key Length = 256 )
+-- Transform PRF ( Name = PRF_HMAC_SHA2_256 )
+-- Transform PRF ( Name = PRF_HMAC_SHA2_384 )
+-- Transform PRF ( Name = PRF_HMAC_SHA2_512 )
+-- Transform INTEG ( Name = AUTH_HMAC_SHA2_256_128 )
+-- Transform INTEG ( Name = AUTH_HMAC_SHA2_384_192 )
+-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 )
+-- Transform D-H ( Name = 8192-bit MODP Group )
+-- Transform D-H ( Name = Curve25519 )
+-- Transform D-H ( Name = Curve448 )
Then complient old implementation will ignore proposals 1 and 2, as
they include Transforms they do not understand, and see that proposal
3 has all the things it needs, and nothing extra, and then it will
pick one value for each Transform Type and return that back i.e., it
might return:
+--- Proposal #3 ( Proto ID = IKE(1), SPI size = 0,
| 4 transforms)
|
+-- Transform ENCR ( Name = ENCR_AES_CBC )
| +-- Attribute ( Key Length = 256 )
+-- Transform PRF ( Name = PRF_HMAC_SHA2_512 )
+-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 )
+-- Transform D-H ( Name = Curve448 )
If you have implementation that do support QSKE algorithm "Zappa", but
not "Foobar", then it will ignore the Proposal 2, as proposal 2 has
QSKE1 transform ID of "Foobar" which it does not support (and as that
has both QSKE1 and QSKE2, so it must pick one value from both. So it
would then pick proposal 1 and return:
+--- Proposal #1 ( Proto ID = IKE(1), SPI size = 0,
| 5 transforms)
|
+-- Transform ENCR ( Name = ENCR_AES_CBC )
| +-- Attribute ( Key Length = 256 )
+-- Transform PRF ( Name = PRF_HMAC_SHA2_512 )
+-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 )
+-- Transform D-H ( Name = Curve448 )
+-- Transform QSKE1 ( Name = Zappa )
Implementation which supports both "Foobar" and "Zappa", can either do
one of them by picking proposal #1, and selecting the one it wants to
do in QSKE1, or it can also pick proposal #2 and do both "Foobar" and
"Zappa", and Foobar will be done as QSKE1 and Zappa is done as QSKE2:
+--- Proposal #6 ( Proto ID = IKE(1), SPI size = 0,
| 6 transforms)
|
+-- Transform ENCR ( Name = ENCR_AES_CBC )
| +-- Attribute ( Key Length = 256 )
+-- Transform PRF ( Name = PRF_HMAC_SHA2_512 )
+-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 )
+-- Transform D-H ( Name = Curve448 )
+-- Transform QSKE1 ( Name = Foobar )
+-- Transform QSKE2 ( Name = Zappa )
> > For these reasons I think a different approach is more
> > convenient: we define new transform types as follows:
> >
> > Transform Type 6: Additional QSKE performed in 1st IKE_AUX
> > Transform Type 7: Additional QSKE performed in 2nd IKE_AUX
> > Transform Type 8: Additional QSKE performed in 3rd IKE_AUX
> > etc. (How many do we want to combine?)
> >
> > The same list of possible Transform IDs representing QSKE
> > methods will be defined for each of these new Transform Types. In
> > addition these QSKE Transform IDs (or some of them with a small
> > enough public key) will also be added to the list of possible
> > Transform IDs for Transform Type 4.
>
> Why not make them all a possible transform id for type 4? After all,
> there are scenarios where fragmentation is not an issue (e.g. TCP
> encaps)
If all of them are Transform Type 4, i.e. D-H, then responder MUST
pick exactly one that is the only one to be used. Responder is not
allowed return more than one Transform ID for each Transform Type
there is in proposal.
> Now, one thing that had been bothering me with our proposal is that
> there is no way to include attributes along with the transform id.
> Now, the existing DH/ECDH transforms do not have any attributes
> defined; however some of the NIST submissions have a large number of
> variations (Round2 had 30 different ones), and while we could make
> each variation a different transform id (which is effectively what
> we did with DH and ECDH; there really is only one DH algorithm; the
> exact transform id selected which parameters were used with that
> algorithm), however it's not clear if that's the approach we want to
> mandate with the newer postquantum transforms.
Each Transform ID can also have arbitrary number of attributes inside,
and the as you can have multiple entries with same Transform Type, but
either different Transform ID or different Attributes inside, the
responder can pick exactly one of the Transform Type of that type, and
include all attributes unmodified.
Currently we only have Key Length attribute, but lets say we later
define "Key Rounds" attribute, then we could have Transform Type ENCR
with following proposals:
+-- Transform ENCR ( Name = ENCR_FOO )
| +-- Attribute ( Key Length = 128 )
| +-- Attribute ( Key Rounds = 16 )
+-- Transform ENCR ( Name = ENCR_FOO )
| +-- Attribute ( Key Length = 256 )
| +-- Attribute ( Key Rounds = 32 )
+-- Transform ENCR ( Name = ENCR_AES_CBC )
+-- Attribute ( Key Length = 256 )
And now responder can return any of the 3 proposed ENCR transforms,
i.e.:
+-- Transform ENCR ( Name = ENCR_FOO )
+-- Attribute ( Key Length = 128 )
+-- Attribute ( Key Rounds = 16 )
or
+-- Transform ENCR ( Name = ENCR_FOO )
+-- Attribute ( Key Length = 256 )
+-- Attribute ( Key Rounds = 32 )
or
+-- Transform ENCR ( Name = ENCR_AES_CBC )
+-- Attribute ( Key Length = 256 )
but nothing else. It cannot modify the attributes in any way.
--
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic