Subject: Re: [IPsec] vendor support of RFC7427

From: Paul Wouters <[email-masked]>
Date: Tue, 20 Jun 2017 13:33:24 -0400 (EDT)

On Mon, 10 Oct 2016, Valery Smyslov wrote:

Valery,

I forgot if we reached any consensus or ideas on the 7427 issue you
brought up in Seoul. Sahana has started work on implementing 7427
for libreswan and during this process we came up with a few questions.

Has there been any discussion about using a hash algorithm that
is different from the one used to sign the CERT (if certificates are
used) ? It seems to not make much sense and lead to false sense of
security if the signature uses SHA2 but the CERT is trusted based on
a SHA1 signature. So, in a way sending more then one hash algorithm
seems to only make sense for raw public keys, not with certificates?

Is it implied that when using SHA2, one twiches the RSA algorithm
variant? If so, how does one know that the old variant is supported?
(I guess that's the issue you brought up in the link below)

Another issue we have in our implementation, is that we don't know which
hash algorithms we allow when needing to send an IKE_INIT response. In
theory, our server could have two connections loaded, one using RSA-SHA1
and one using ECDSA-SHA2. These connections can only be selected
when we receive the IKE_AUTH packet. So our implementation picks one
(sort of randomly) and when processing IKE_AUTH it can "switch" to the
other connection. But we already have to commit to a hash algorithm
in the IKE_INIT reply. And if we are sending ALL the hash algorithms that
we support/implement, then we run the risk of the peer expecting to be
able to use some hash algorithm, but we don't allow it per configuration
for that specific connection (eg the SHA2 one on the RSA-SHA1 connection)
and there is no way to signal that other then AUTHENTICATION_FAILED.

Paul

> Subject: Re: [IPsec] vendor support of RFC7427

> Hi,
>  
> we (ELVIS-PLUS) support RFC7427 for over a year and we are interoperable with Strongswan.
>  
> However, see my message about some interoperability problems:
> https://www.ietf.org/mail-archive/web/ipsec/current/msg10840.html
>  
> This issue is scheduled for discussion on ipsecme meeting in Seoul.
>  
> Regards,
> Valery Smyslov.

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 21 Jun 2017 10:01:23 +0300

Hi Paul, 

> for libreswan and during this process we came up with a few questions.

My impression was that most of participants considered the problem 
insignificant. But I wouldn't call this a consensus.

> seems to only make sense for raw public keys, not with certificates?

I don't think so. The responder usually doesn't know which certificate
the initiator will use in IKE_AUTH, so it has to announce support for
all supported hashes.

> (I guess that's the issue you brought up in the link below)

Yes. The IKE peer can announce which hash algorithms it supports,
but it cannot announce which signature formats it supports.
For example, with RSA we have at least two widely used - RSA-PKCS1 and RSA-PSS.
We did meet a situation when one product supported RSA-PSS in 
certificates, but didn't support it in IKE AUTH, so that we received
AUTHENTICATION_FAILED if we used RSA-PSS. As initiator we can
retry with RSA-PKCS1 (however it is ugly), but as responder we cannot, 
so the connection just failed. If there were means to announce 
support for particular signature formats, then we would have used 
this format (RSA-PKCS1 in the example above) and the connection 
would succeed.

I guess similar problem can arise in the future with other signatures - 
we now see  some new signature schemes emerging (EdDSA, XMSS etc.).

> and there is no way to signal that other then AUTHENTICATION_FAILED.

This is even a more fundamental problem with IKEv2 - the responder cannot have
per-peer policy (e.g. if server's policy states, that IKE SA with client [email-masked]
must be secured with AES and IKE SA with client [email-masked] must be secured 
with Chacha20, and both clients send both algorithms in IKE_SA_INIT, then the server
in general cannot enforce this policy, because it must select a single algorithm before it 
figures out who the client is). It seems that the only solution is to have a global policy for IKE. 
So, in your particular example the server should announce both hashes (assuming both 
are strong enough).

Regards,
Valery.