From: Valery Smyslov [mailto:[email protected]]
Sent: Saturday, February 20, 2016 3:12 AM
To: Scott Fluhrer (sfluhrer); [email protected]
Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01
Hi Scott,
thank you for issuing a new version of the draft that addresses most of my
comments on -00 version.
However I still have some concerns. I'm not happy with the way algorithm
agility support is added
into the draft.
Currently the draft specifies PPK Indicator Algorithm as a 4 bytes long integer
with a single
defined value of 1 (AES256_SHA256). This definition does imply the need for new
registry since more algorithms would be specified. I don't see any compelling
reason to add a new registry,
since the existing registries can be reused.
I'd propose the following way to support algorithm agility.
When the responder receives the initial request with PPK_REQUEST notification,
it parses
SA payload collecting all PRF type transforms. The result is the list of PRFs
the initiator
supports. The responder picks the most preferred PRF from the list and returns
its value (as defined in the IKEv2 registry "Transform Type 2 - Pseudo-random
Function Transform IDs")
as PPK Indicator algorithm in PPK_ENCODE notification. The PPK indicator is
computed
using this PRF as foolws:
ppk_indicator = PRF(PRF(ppk, "A"), ppk_indicator_input)
This proposal has the following advantages.
1. Reusing existing IKEv2 registry
2. Better interoperability, since the PRF transform is mandatory in the SA
payload
in IKEv2 and the responder can always be sure that the chosen PRF is
supported
by the initiator. With the current proposal the situation is possible when
the initiator includes, for example, only AEAD transforms in SA payload.
In this case even AEAD transform is (for example) AES based, there is no
guarantee
that plain AES encryption is also supported by the initiator.
3. The current PPK Indicator Algorithm field combines 2 algorithms - encryption
and prf.
Actually, it doesn't - it only implements the "PPK hint" algorithm.
Once more algorithms are supported as PPK indicator the size
of the registry will be grown quickly since every new prf will be combined
with every new cipher (yes, it can be limited by combining only
selected prfs with only selected ciphers, but that would reduce
interoperability).
I would personally be surprised if there are any more algorithms added to the
registry. The current algorithm works quite well, if we believe that AES is
even slightly secure. The only reason I could see if someone asked for
something new is if they had issues actually implementing AES.
This would make the idea of precomputing ppk indicators on responder
less efficient (you may easily precompute the whole ppk database using few
popular PRFs, but if these PRFs are combined with ciphers -
the resulting number of their combinations could become too big).
With my idea, if you support only one PPK indicator algorithm, you need to
precompute each PPK once (if the server fixes the PPK indicator input). With
your idea, you'd need to redo it for every PRF you support. How is this an
advantage for your idea?
I see the only disadvantage of this proposal. As you wrote you specifically
used combination of encryption and PRF since AES is supported in hardware
on some CPUs and thus gives some performance advantages over PRF-only
scheme. I don't think it is a compelling argument.
Actually, I would argue that it is. One complaint I've heard is that this
would require the server to scan through its list of PPK's for every session it
gets. The current draft allows a server to reissue PPK indicator inputs to
reduce this impact; however we would prefer servers to reissue PPK indicator
inputs are rarely as possible. Making the evaluation of the PPK algorithm
cheaper encourages implementations to do this.
It reflects only the current
situation in the industry and may change over time.
It may, but likely won't. Intel has announced hardware support for
accelerating SHA-1 and SHA-256; however I believe that even with that support,
one AES-NI evaluation of AES-256 will be faster than two evaluations of the
block compression of either SHA-1 or SHA-256 (assuming the PRF is either
HMAC-SHA1 or HMAC-SHA256)
I don't think the protocol
should be based on such shaky grounds. Am I missing something?
>From where I stand, it would appear that the main advantage of your proposal
>is "we won't have to ask IANA for another registry". Am I missing something?
Few editorial issues:
1. Abstract
No point at the end of the abstract.
2. Section 1
[The general idea is that we add an additional secret that is shared
between the initiator and the responder; this secret is in addition
to the authentication method that is already provided within IKEv2.]
s/in addition/an addition ?
3. IANA Considerations section is missing.
Regards,
Valery Smyslov.
Last year, NSA made an announcement about how to deal with the potentiality of
someone developing a Quantum Computer;
(https://www.nsa.gov/ia/programs/suiteb_cryptography/). Among their
recommendations was the advice that:
"CSfC deployments involving an IKE/IPsec layer may use RFC 2409-conformant
implementations of the IKE standard (IKEv1) together with large, high-entropy,
pre-shared keys and the AES-256 encryption algorithm. RFC 2409 is the only
version of the IKE standard that leverages symmetric pre-shared keys in a
manner that may achieve quantum resistant confidentiality.
The reason they gave this advise was the IKEv1, unlike IKEv2, stirred in the
preshared key into the KDF function (along with the (EC)DH shared secret);
hence if the preshared key was strong, then Shor's algorithm (which can recover
the (EC)DH shared secret) is not enough to recover the negotiated keys.
Now, we don't want people to migrate back to an obsolete version of the
protocol; hence we've devised a way to strengthen IKEv2 the same way.
It was considered important to minimize the changes made to IKEv2. From a
cryptographical prespective, the only change we make is that we modify the
nonces that we present to the KDF. By keeping the cryptographical changes
minimal, we reduce the risk of accidentally introducing a weakness.
Like IKEv1, this solution assumes that the initiator and the responder share a
secret string (called a PPK in the draft). However, unlike IKEv1, that is not
the only authentication that's in the system. We leave the existing
authentication methods in place, and add this in addition.
One thing that was a source of complexity was that we did not want to assume
that every system had the same PPK; that instead that systems would want a
pairwise PPK. However, if a responder configured its PPK on a per-peer basis,
and didn't learn the peer until after an IKEv2 tunnel has been established,
that would mean that the responder would need to know the PPK before it
officially learned the peer. To solve this, we added the
PPK_REQUEST/PPK_ENCODE notifications to give the responder a hint about which
PPK to use (without leaking the identity to third parties).
Would anyone be willing to review this draft? I believe that we have a need
for such a solution.
________________________________
_______________________________________________
IPsec mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
