[IPsec] Comments on draft-smyslov-ipsecme-ikev2-auth-announce

[Tero Kivinen <[e-mail]>]

Scott Fluhrer \(sfluhrer\) writes:
> I’m glad to see this work; however I see a potentially important
> constraint on authentication that the current draft does not appear
> to address.
> 
> It allows the peers to specify which signature algorithms they
> accept; however if we are talking about certificates, those include
> internal signature algorithms, which may be different. One instance
> where I expect this to come up is that the root certificate may have
> a more conservative algorithm choice (e.g. a hash based signature,
> or one with NIST level 5) than the device certificates (which may
> have a short expiry time, and so being so conservative might not be
> necessary).
> 
> Does the AuthMethod apply to the algorithms within the certificate
> as well? The RFC should clarify this.

The reason for this notify is that if the peer has multiple key pairs
(i.e., private keys) it needs to pick one private key to sign the AUTH
payload with. If one of those private keys is using EC and another is
using RSA, then without this notification there is no way of knowing
which one to pick (except perhaps by prior configuration or by
heuristics based on the CERTREQ etc).

Also in some cases same private key can be used with multiple hashing
methods etc, thus indicating what formats of signature are accepted is
also needed.

On the other hand the signatures in the certificates are already
there, and the peers do not have any way of changing them, thus
negotiating what are accepted does not help. Peers can already send as
many certificates they want and they can also indicate the CAs they
trust using CERTREQs, so that should be enough for peers to get
algorithms in the certificates sorted out.

I.e., if they have multiple paths from certificate(s) matching their
private key they are going to use for signing to the trusted roots
trusted by other end, they can send all those paths out.

The one who gets all those certificate payloads will then search from
them, and from its local cache, or even querying more intermediate
certificates from the CA and form a trusted path from the one EE
certificate to any trusted root that matches the security policy
required for the that end.
-- 
[e-mail]