Hi Scott,
please see inline.
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.



I meant that in your proposal the “PPK hint” algorithm uses two

crypto primitives – a cipher (AES) and a prf (HMAC_SHA256).

I’d rather get rid of cipher and redefine the “PPK hint” algorithm

using sole prf (as shown above). Why do I want this?

Because it would allow to reuse an existing IKEv2 registry 

that defines Transforms of Type PRF. Why  is it important for me? 

Currently you defined the only value for “PPK hint” algorithm - 

AES256+HMAC_SHA256. If additional values are defined, then

the responder will have to decide what algorithm to choose

talking with particular initiator. One (and probably the most important)

of selection criterias is the following: the algorithm must be mutually 
supported 

by the initiator and the responder. In your current proposal there is no 
explicit 

indication from the initiator which algorithms it supports and the responder

will need to use a heuristics (for example, if the initiator proposes using

AES-GCM for an encryption, does it mean that AES-ECB is also supported?

It may sound silly, but I can imagine the situation when AES-GCM is

supported, while AES-ECB – not, for example if all crypto is performed

in dedicated hardware). Redefining “PPK hint” algorithm to use

sole PRF would allow the responder to have explicit and reliable

information when choosing the mutually supported algorithm:

it is the list of PRFs present in the initiator’s SA payload.

 

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.

 

>From my point of view there are two main reasons for defining additional 
>algorithms,

both quite real. First, some countries have a legacy restrictions on using 
non-government approved

crypto algorithms in some situations. For example, here in Russia you must use 
only GOST if you 

make products for government structures. Second, some constrained devices may 
implement

very limited set of crypto primitives, and it doesn’t necessary includes AES 
and SHA2. 

As an implementer I don’t want to waste resources (both device’s and human) to 
add AES and SHA2 

to them if it is possible to reuse existing crypto.

 

    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?

 

It is a local matter of responder how it manages its PPKs. I can see at least 
three possible

approaches. The first one – the responder may choose not to precompile PPK 
hints at all.

It is the worst case in terms of consuming its CPU power, but it would allow

the server to use random data for each initiator, thus completely protecting 
their privacy.

Second approach – as you suggest, when the responder fixes the PPK indicator

input for some perion of time and then precompiles PPK hints for all the 
supported PRFs.

You are right - the more PRFs it supports the more resources it consumes while 
precompiling. 

Both approaches are trivial.

I’d envision third approach, which is a combination of the two. The responder 
needs not

to precompile hints beforehand. When it receives a PPK hint from the initiator

it starts searching for the PPK by applying “PPK hint” algorithm to every PPK, 
as in the first

approach, until the correct PPK is found. However, the responder saves every 
usuccessful result

in a PPK hint cache, so that when the next client appears, the cache is 
consulted first and

only if the PPK is not found via the cache, the responder continues to search 
remaining

PPKs with PPK algorithm. This approach allows the responder not to waste 
resources

precompiling the hints for every PPK it has and every PRF it supports if some 
PPKs

and PRFs are not used during the lifetime of the PPK indicator input.

I think this approach would mitigate the need to spend more resources in case 
of several PRFs are supported.

 

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.

 

That’s true. The question is whether what is “cheaper” today will still be 
“cheaper” tomorrow 

(and please multiple this by the number of HW platforms that exists in the 
world).

 

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)

 

Sorry, I can’t buy this. Intel is not the only CPU manufacturer out there. And 
don’t forget about dedicated crypto hardware.

I’d like to see a generic solution not based on momentary trends in the 
industry.

 

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?



Mostly, however that’s a bit oversimplified. Reusing existing registry is not 
the most important advantage per ce, 

it would just allow to get other advantages, like better interoperability when 
more PPK algorithms are defined,

reusing of existing code for parsing PRF transform in SA payload, easying the 
procedure of adding new

PPK algorithms (once new PRF is added by IANA it automatically can be used in 
PPK hint algorithm) and so on.

By the way, it even decreases the size of PPK_REQUEST notification by 2 bytes! 
:-)

 

Regards,

Valery.



 

 

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
  IPsec@ietf.org
  https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to