Re: [IPsec] NIST question concerning IKEv2 and quantum resistance

[Valery Smyslov]

Hi Scott,


Scott Fluhrer (sfluhrer)  wrote:
> - It defines the transform of the nonce from the on-the-wire version into
the
> one presented to the IKEv2 KDF (mixing in the PPK).

> - The initiator gives an indication of which PPK to use (without leaking 
any
> information about it to someone two doesn’t know the value).

> For the first use, it would be reasonable to have the initiator define a
> bitmask of the algorithms it supports, and the responder to select one

That's not very algorithm agile, nor very IKEv2 happy. Don't we already have
IANA values for all the algorithms involved? (shouldn't we have them)


The 'bitmask idea' was off the top of my head; we could certainly give a list of
IANA values (such as the IKEv2 PRF).  My chief fear is that we don't 
overengineer
this; this really is a "short term solution" (with the usual caveat that there 
are no
short term solutions), and that a post-quantum DH-like function is the Right 
Thing
(only we haven't agreed on that yet).  The issue with having a complex 
negotiation
process is that may be a lot of rarely executed code, and that in itself may 
lead
to security vulnerabilities.


Is it possible to use the already negotiated IKEv2 prf inside the modified 
crypto formulas?
In this case they would look like:

   SKEYSEED = prf(prf(ppk, Ni) | prf(ppk, Nr), g^ir)
   (SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr) =
 prf+(SKEYSEED, prf(ppk, Ni) | prf(ppk, Nr) | SPIi | SPIr)

and so on. I'm not a cryptographer, but it seems to me that this is safe, isn't 
it?
In this case no additional negotiation is required since prf is negotiated in 
IKEv2
anyway and thus we would have algorithm agility in KDF for free.


> This second use is rather trickier to have agility; it is sent before the
> initiator has any contact to the responder. I don’t see how the
> responder can
> indicate which algorithms it supports (without adding a round trip to the
> protocol).

This is why I suggested... if you have to add a round trip anyway... might as
well solve a puzzle or something along the way.


One of the constraints that we felt we had to live within was to minimize
the changes we made to IKEv2, both from a crypto standpoint, and from
a state machine standpoint.  Hence, we decided that adding vendor
id payloads (or notification payloads) to existing messages we OK,
however adding additional round trips was out of bounds.


Note, that IKEv2 state machine has already accomodated the possibility
of an additional round trip in case the initiator has incorrectly guessed the
DH group. Introducing one more condition for additional round trip
should not be too hard, however I agree that it adds some complexity
and thus may be considered inappropriate for a short-term solution.

However, if no better solution exists I'd prefer to live with a single
fixed crypto primitive, than with two. Is it possible to get rid of
AES and to change the indication of the ppk to use to something
like the following?

HMAC_SHA256(HMAC_SHA256(ppk, "A"), random_bytes)

(disclaimer: I'm not a cryptographer)


If one were to add additional round trips, a cleaner solution would be
to negotiate the initial IKE SA as per the RFC, and then if the two sides
decide that they need QR, create a child SA (in a PQR manner).
The current approach has the issue that we need to stir in the post-quantum
magic before the identities were exchanged (and hence the initiator gives
the indication of the ppk). If you establish a secure connection (and exchange
identities) first, then it becomes much cleaner (as both sides would know who
they are talking to, and which ppk they should use).  However, that was
deemed to be too large of an delta.


I'm not sure this approach is easier than approch with additional round trip.
I understand that it has some advantages (e.g. no need for linear key search),
but from state machine point of view it may appear to be more complex.

Regards,
Valery. 


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] meeting at IETF-95 ?

[David Schinazi]

+ 1

David


> On Jan 13, 2016, at 14:51, Yoav Nir  wrote:
> 
> I believe around that time CFRG and TLS will be done with the signatures 
> document and rfc4492bis respectively, so we could proceed and finish 
> draft-ietf-ipsecme-safecurves.
> 
> So count me as a +1 as well.
> 
>> On 12 Jan 2016, at 4:56 PM, Paul Wouters  wrote:
>> 
>> 
>> I hope we are scheduling a meeting for IETF-95. Last time we did not
>> meet and ended up meeting in the hallway. This time there are more
>> drafts being suggested and worked on.
>> 
>> Paul
>> 
>> ___
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] IPsec Digest, Vol 141, Issue 16

[Les Leposo]

> On 14 Jan 2016, at 11:00 PM, ipsec-requ...@ietf.org wrote:
> 
> Send IPsec mailing list submissions to
>   ipsec@ietf.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://www.ietf.org/mailman/listinfo/ipsec
> or, via email, send a message with subject or body 'help' to
>   ipsec-requ...@ietf.org
> 
> You can reach the person managing the list at
>   ipsec-ow...@ietf.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of IPsec digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: NIST question concerning IKEv2 and quantum resistance
>  (Paul Wouters)
>   2. Re: meeting at IETF-95 ? (David Schinazi)
> 
> 
> --
> 
> Message: 1
> Date: Thu, 14 Jan 2016 11:28:00 -0500 (EST)
> From: Paul Wouters 
> To: "Scott Fluhrer (sfluhrer)" 
> Cc: "ipsec@ietf.org" 
> Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum
>   resistance
> Message-ID: 
> Content-Type: text/plain; charset=US-ASCII; format=flowed
> 
> On Thu, 14 Jan 2016, Scott Fluhrer (sfluhrer) wrote:
> 
>>> Is it possible to use the already negotiated IKEv2 prf inside the modified
>>> crypto formulas?
>>> In this case they would look like:
>>> 
>>>SKEYSEED = prf(prf(ppk, Ni) | prf(ppk, Nr), g^ir)
>>>(SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr) =
>>>  prf+(SKEYSEED, prf(ppk, Ni) | prf(ppk, Nr) | SPIi | SPIr)
>>> 
>>> and so on. I'm not a cryptographer, but it seems to me that this is safe, 
>>> isn't
>>> it?
>>> In this case no additional negotiation is required since prf is negotiated 
>>> in
>>> IKEv2 anyway and thus we would have algorithm agility in KDF for free.
>> 
>> I like this -- I'm stealing this idea.
> 
> Note that using a hash of a hash is frowned upon. See the latest SLOTH
> on TLS for an example of a collision attack that used the fact that a
> hashed message got hashed again (unlike IKE which hashes only the data)

imho, the level of weakness would depend on the selected hash algorithms and 
the input’s number space.

for instance, if the number space for the input is huge, and the size of 1st 
vs. 2nd hash reduces significantly, plus the (pseudo) randomness of the hashes 
reduces then it would be a bad direction, I’d think.

[not a cryptographer]

> 
> Paul
> 
> 
> 
> --
> 
> Message: 2
> Date: Thu, 14 Jan 2016 09:16:16 -0800
> From: David Schinazi 
> To: Yoav Nir 
> Cc: "ipsec@ietf.org WG" 
> Subject: Re: [IPsec] meeting at IETF-95 ?
> Message-ID: <4a3ba7c8-3aca-4250-8464-23cc89f10...@apple.com>
> Content-Type: text/plain; charset=us-ascii
> 
> + 1
> 
> David
> 
> 
>> On Jan 13, 2016, at 14:51, Yoav Nir  wrote:
>> 
>> I believe around that time CFRG and TLS will be done with the signatures 
>> document and rfc4492bis respectively, so we could proceed and finish 
>> draft-ietf-ipsecme-safecurves.
>> 
>> So count me as a +1 as well.
>> 
>>> On 12 Jan 2016, at 4:56 PM, Paul Wouters  wrote:
>>> 
>>> 
>>> I hope we are scheduling a meeting for IETF-95. Last time we did not
>>> meet and ended up meeting in the hallway. This time there are more
>>> drafts being suggested and worked on.
>>> 
>>> Paul
>>> 
>>> ___
>>> IPsec mailing list
>>> IPsec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipsec
>> 
>> ___
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
> 
> 
> 
> --
> 
> Subject: Digest Footer
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> 
> --
> 
> End of IPsec Digest, Vol 141, Issue 16
> **

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] SLOTH & IKEv2

[Valery Smyslov]

Hi Paul,


Is it possible to use the already negotiated IKEv2 prf inside the modified
crypto formulas?
In this case they would look like:

SKEYSEED = prf(prf(ppk, Ni) | prf(ppk, Nr), g^ir)
(SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr) =
  prf+(SKEYSEED, prf(ppk, Ni) | prf(ppk, Nr) | SPIi | SPIr)

and so on. I'm not a cryptographer, but it seems to me that this is safe, isn't
it?
In this case no additional negotiation is required since prf is negotiated in
IKEv2 anyway and thus we would have algorithm agility in KDF for free.


I like this -- I'm stealing this idea.


Note that using a hash of a hash is frowned upon. See the latest SLOTH
on TLS for an example of a collision attack that used the fact that a
hashed message got hashed again (unlike IKE which hashes only the data)


Not really. IKE does use prf inside prf. Let's expand SK_* computation formula:

SK_* = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr) = 
prf (prf(Ni | Nr, g^ir), Ni | Nr | SPIi | SPIr | 0x01) | 
prf (prf(Ni | Nr, g^ir), prf (prf(Ni | Nr, g^ir), Ni | Nr | SPIi | SPIr | 0x01) | Ni | Nr | SPIi | SPIr | 0x02)

and so on.

I don't think it's wrong from cryptography point of view if the prf is not broken 
(usual disclaimer: I'm not a cryptographer).


However, thank you for bringing in the SLOTH attack.
As fas as I understand from the paper http://www.mitls.org/downloads/transcript-collisions.pdf 
it is based on the ability for an attacker to find collisions in a weak hashes 
(md5 and sha1). In particular the authors uses chosen-prefix collision attacks

to break some security protocols. They mostly focused on breaking TLS,
but Section VI contains description of a possible attack on IKEv2.

As far as I understnd the attack on IKEv2 it is based on the cookie request
feature. The attacker makes a cookie request to the initiator
with the cookie crafted in such a way, that the hash of the IKE_SA_INIT message
containing this cookie would collide with the hash of the IKE_SA_INIT message
containing attacker-chosen KE payload. It would allow the attacker
to impersonate the initiator.

If I got it right the ability for an attacker to quickly find a hash collision
is based (besides using weak hashes) on presumption that 
the cookie is always the very first payload in the message,

as depicted in the Section 2.6 in the RFC 7296. So it is
presumed that the cookie always preceedes any unpredictable
for the attacker values in the message, that allows to perform
an effective chosen-prefix attack on a hash.

So, I think that we can completely thwart this attack (regardless
on the possible weakness of the used hashes) if we make
a recommendation for implementers to put the cookie at the
end of the message. RFC 7296 doesn't imply any restrictions
on the payloads order. However the Section 2.6 states:

  If the IKE_SA_INIT response
  includes the COOKIE notification, the initiator MUST then retry the
  IKE_SA_INIT request, and include the COOKIE notification containing
  the received data as the first payload, and all other payloads
  unchanged.  

It's a bit unclear for me whether this MUST is concerned with 
the requirement to retry request only, in which case it is only

a recommendation to place the COOKIE before other payloads,
or the MUST is also applied to the text that COOKIE is the 
first payload (that would be unfortunate).


What does IPsec community think of it? Should we fix the protocol
to thwart this attack completely? Is the recommendation to 
move the COOKIE to the end of the message enough to achive that?

Will this change break many existing implementations?

Regards,
Valery Smyslov.



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] NIST question concerning IKEv2 and quantum resistance

[Scott Fluhrer (sfluhrer)]

> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Valery Smyslov
> Sent: Thursday, January 14, 2016 7:58 AM
> To: Scott Fluhrer (sfluhrer); Michael Richardson; ipsec@ietf.org
> Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance
> 
> Hi Scott,
> 
> >> Scott Fluhrer (sfluhrer)  wrote:
> >> > - It defines the transform of the nonce from the on-the-wire
> >> version into the
> >> > one presented to the IKEv2 KDF (mixing in the PPK).
> >>
> >> > - The initiator gives an indication of which PPK to use (without 
> >> leaking
> any
> >> > information about it to someone two doesn’t know the value).
> >>
> >> > For the first use, it would be reasonable to have the initiator 
> >> define a
> >> > bitmask of the algorithms it supports, and the responder to
> >> select one
> >>
> >> That's not very algorithm agile, nor very IKEv2 happy. Don't we
> >> already have IANA values for all the algorithms involved? (shouldn't
> >> we have them)
> >
> > The 'bitmask idea' was off the top of my head; we could certainly give
> > a list of IANA values (such as the IKEv2 PRF).  My chief fear is that
> > we don't overengineer this; this really is a "short term solution"
> > (with the usual caveat that there are no short term solutions), and
> > that a post-quantum DH-like function is the Right Thing (only we
> > haven't agreed on that yet).  The issue with having a complex
> > negotiation process is that may be a lot of rarely executed code, and that 
> > in
> itself may lead to security vulnerabilities.
> 
> Is it possible to use the already negotiated IKEv2 prf inside the modified
> crypto formulas?
> In this case they would look like:
> 
> SKEYSEED = prf(prf(ppk, Ni) | prf(ppk, Nr), g^ir)
> (SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr) =
>   prf+(SKEYSEED, prf(ppk, Ni) | prf(ppk, Nr) | SPIi | SPIr)
> 
> and so on. I'm not a cryptographer, but it seems to me that this is safe, 
> isn't
> it?
> In this case no additional negotiation is required since prf is negotiated in
> IKEv2 anyway and thus we would have algorithm agility in KDF for free.

I like this -- I'm stealing this idea.

> 
> >> > This second use is rather trickier to have agility; it is sent 
> >> before the
> >> > initiator has any contact to the responder. I don’t see how the
> >> > responder can
> >> > indicate which algorithms it supports (without adding a round trip to
> the
> >> > protocol).
> >>
> >> This is why I suggested... if you have to add a round trip anyway...
> >> might as well solve a puzzle or something along the way.
> >
> > One of the constraints that we felt we had to live within was to
> > minimize the changes we made to IKEv2, both from a crypto standpoint,
> > and from a state machine standpoint.  Hence, we decided that adding
> > vendor id payloads (or notification payloads) to existing messages we
> > OK, however adding additional round trips was out of bounds.
> 
> Note, that IKEv2 state machine has already accomodated the possibility of an
> additional round trip in case the initiator has incorrectly guessed the DH
> group. Introducing one more condition for additional round trip should not
> be too hard, however I agree that it adds some complexity and thus may be
> considered inappropriate for a short-term solution.
> 
> However, if no better solution exists I'd prefer to live with a single fixed
> crypto primitive, than with two. Is it possible to get rid of AES and to 
> change
> the indication of the ppk to use to something like the following?
> 
> HMAC_SHA256(HMAC_SHA256(ppk, "A"), random_bytes)
> 
> (disclaimer: I'm not a cryptographer)

Your proposal is perfectly sound from a cryptography perspective.  Actually, 
the reason we proposed the "entry in the AES codebook" approach, rather than 
something like the above structure, is due to practical reasons.  When the 
responder receives the hint, he has no idea which ppk the initiator is 
referring to (and he doesn't know the identity yet); our model is that the 
responder has a list of ppk's that he knows about, and checks to see if the one 
that the initiator had is on the list.  It'd be nice if there was a way for the 
responder to search through his databases of known ppk's quickly, however I 
don't know how to let him do it in sublinear time (without leaking whether two 
exchanges used the same ppk, which would leak information about the 
identities).  So, what we settled on is to make the linear scan for the right 
PPK as fast as possible.  With our proposed solution, an aggressive responder 
could have all the AES keys corresponding to the ppk preexpanded, and just 
check each potential ppk by doing one AES block encryption (or decryption, if 
they prefer); if the implementation has AES-NI, that is fairly fast.  With your 
proposal, they could preexpand the HMAC keys, but would still need to do two 
SHA256 compression function