Hi Tero,
One question that comes to my mind is that why is the server offering
CA which issues RSASSA-PSS certificates it is does not support those
certificates. I.e. server is saying it will use CA which it cannot
use, and I would say that is configuration error in the server side.
Well, if we are talking about the specific product we ran into interoperability
problem with, then its behavior is a bit different. It does support
RSASSA-PSS signatures in certificates, however it cannot use RSASSA-PSS
signatures in IKE. I guess that the reason for such behaviour is because
the certificate processing (including signature verification) is performed by
some cert lib, while IKE signature forming/verification is performed by another
piece of code.
Also usually client will know which certificate it must use when
connecting to the server, exactly as it must know which PSK it must
use when it connects to which server.
There is no indication in certificate that the public key it contains
must be used explicitely with RSASSA-PKCS#1 or RSASSA-PSS.
So, the client does know which certificate to us, it doesn't know
which form of signature to use.
I can see that there are corner cases where the adminstrative domain
is updating from PKCS#1 certificates to the RSASSA-PSS, and not all of
its infrastructure is updated yet, but it can prevent issues by either
making sure server sides are updated before clients,
There are use cases when both peers can act as initiator and responder (SG-SG).
or using separate CA for different key types.
Very inconvenient.
Another case where this might happen when
client is doing opportunistic encryption i.e., it does not even try to
authenticate, thus it does not care which key it is using or what key
the other end is using, thus it will just pick one of its own keys and
use that.
In most cases IPsec is considered as "requires preconfiguration" use
case, i.e., I cannot random try to connect host A with IPsec and
assume that will work. It is same thing with secure shell, i.e.,
unless I have account and password or key configured for host A, there
is no point of trying to see if I can log in to the host A. I.e., if
you need to configure that this is the CA I want to trust when
connecting to host A, and this is the identity I am going to use for
myself, it is not that much more to configure that this is the key I
am going to use when authenticating to host A. With PSK I will need to
explictly give the keys anyways, why should the certificates be that
much different case, that you cannot preconfigure the key you are
using.
TLS and HIP are examples of cases which are more or less "no
preconfiguration required", i.e., you can just try to connect and if
it works then you can use connection.
I think that is true only for HTTPS use case, when TLS client is preconfigured
with a bunch of trusted CAs and the authentication is performed one-way.
Is not true for TLS in general.
This is the reason why the RFC7427 only negotiates the hash algorithm,
and the section 5 of the RFC 7427 gives several ways of solving this
issue without doing protocol changes.
No, section 5 is about a different problem: how to select
a proper certificate, if we have several certificates containing
public keys for different signature algorithms.
Now we have the only certificate (or raw key), but we don't
know how to use it, because there are more than one way of
using it and the peer doesn't inform us what it supports.
I still think this is more or less a configuration mismatch issue,
i.e., if your configuration is wrong you will end up in trouble, but
if you plan your upgrade process, or configure your systems correctly,
this issue is disappears.
In some cases it can be solved by additional configuration option,
but I dont't think in all. The other option for initiator is to retry
IKE SA in case it receives AUTHENTICATION_FAILED. But it is
very bad option and I'd rather resolve it by protocol means.
RSASSA-PSS is just a specific problem we ran into, I suspect
we can have the same sort of problem in future with other signature
algorithms, provided their number is nowdays increasing
rapidly.
Regards,
Valery.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
