Re: [IPsec] draft-fluhrer-qr-ikev2-01

["Valery Smyslov" <[e-mail]>]

Hi Tero,

>> I think this proposal is worse than presented in the draft.
>> It leaves information in the IKE SA vulnerable to QC-based attacks.
> 
> And what information do you think is there that is really worth of
> protecting?

If we are talking about the original IKEv2 as specified in the RFC 7296,
then there are not much sensitive data inside the IKE SA - mostly identities,
traffic selectors and configuration attributes (althouth I think all these items 
must still receive due protection).

However, I've been always thinking that IKE SA can be used as a transport 
for low volume data (for example using Transaction exchange). I'm sure there are 
propriatory extensions out there and I wonder why nobody try to standardize it yet.

There is also a draft describing IKEv2 based protocol for group key 
management (draft-yeung-g-ikev2) and it does tramsmit sensitive
information (including session keys) inside IKE SA.

It is a pity if QC protection mechanism won't work for these IKEv2 variants
(as in your proposal).

> My understanding is that when there really are attackers using
> QC-based attacks in real, we need to change the IKEv2 again, to make
> the authentication methods also protected against QC-based attacks.

Note, that the proposed solution also protects authentication
(since SK_px are used in calculation of the AUTH payload content).

> What we are solving now is the fact that someone can save all the
> IKEv2 / IPsec traffic now, and when they do get the quantum computers,
> they can break the Diffie-Hellman and then get the traffic keys used
> to protect the IPsec traffic.
> 
> I.e. the saving of traffic happens now and breaking of the traffic
> happens much later.
> 
> What information there are in the IKEv2 SA which is important to
> protect for that kind of attacks?

See above. For some derivation of IKEv2 (like G-IKEv2)
there are a lot of sensitive information to protect.

>> Moreover, the way PPK is used in the draft is more clear and 
>> easier to implement. Note, that the only difference between the crypto
>> formulas from RFC7296 and the draft is that every use of Nx (where x = [ir]) 
>> is replaced with PRF(PPK | Nx). It is simple and modular from 
>> implementer's point of view.
> 
> The draft had all kind of talks about AES and SHA256, so I just assume
> that was there to confuse people and it is not needed?

Please, re-read the draft. In the last version it is not tied with any
particular algorithms (AES, SHA256) and uses the negotiated 
PRF for SKEYSEED calculation.

>> Moreover, in this case the PPK is used as the key for PRF, while in
>> your proposal the PPK is used as additional data fetched into PRF.
> 
> The reason I used that is that cryptographers who designed the IKEv2
> did that same thing with the share secret output from the
> Diffie-Hellman, i.e., the g^ir. So I do assume that is safe, and if it
> not then we need some proper cryptographer to tell me why not.
> 
> Also using the PPK as key to the PRF will limit the size of the PPK to
> match you PRF key length. Using it as a data is supposed to be better
> if I remember right why this method was selected for the IKEv2.

Most PRFs accept key of arbitrary length. And if some PRF
is defined with a fixed length key, that there will be a problem
with this PRF in IKEv2 anyway - with calculation of SKEYSEED,
where key is a concatenation of the nonces. That's why
an ugly hack for AES-XCBC-PRF-128 and AES-CMAC-PRF-128 
is included in the protocol.

> Anyways I am not cryptographer, I just assume that the people who are
> and who said it is ok to do 
> 
> KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr)
> 
> know what they were doing.

I'm not a cryptographer either, but I think that from cryptography
point of view your construction is sound. The problem resides
in implementation, not in mathematics. See below.

>> Using secret material (PPK) as a data is always a pain for the
>> products that maintain "security core", while using secret as a key
>> is simple and natural.
> 
> But this what we do in IKEv2 for all cases, also the SKEYSEED is
> calculated in same way:
> 
> SKEYSEED = prf(Ni | Nr, g^ir)
> 
> I.e. the public values Ni and Nr are used as key, and the shared
> secret g^ir is used as data.
> 
> If you think that is unsafe, I would like to get more information
> about that, as that would mean that we need to change the
> cryptographic protocol used in the IKEv2...

I never meant that it is unsafe. I meant that sometimes it causes 
a headache for implementers when long-term secret is used
as a data in cryptographic formulas. Consider the situation when
you have a dedicated hardware (HSM, token) where long-term
secrets reside. Very often this hardware has an API that 
never allows the secrets to be exposed and allows them to be used 
only as keys in cryptographic primitives (i.e. you can encrypt
some data using these key). If you need to use these keys
as data in cryptographic primitives then you must either contact
the hardware manufacturer and ask him for a new API function
specific for your needs or to find some workarounds, that
are often based on undocumented features.

Note that g^xy is a different beast - it is not a long-term
secret, and usually APIs allow using session keys
as a data in key derivation functions. 

Regards,
Valery.