Re: [IPsec] vendor support of RFC7427

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

Hi Paul, 

> 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.

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

> 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?

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.

> 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)

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.).

> 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.

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 [e-mail]
must be secured with AES and IKE SA with client [e-mail] 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.

> 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.