[strongSwan] understanding %fromcert

[Daniel Pocock]

On 15/07/13 20:18, Andreas Steffen wrote:
> Hi Daniel,
>
> your proposal certainly makes sense. But often a certificate contains
> multiple subjectAltNames (e.g. several e-mail addresses, fully
> qualified domain names or rather rarely IP addresses). A notation
> as
>
>   leftid=%san2
>
> only makes sense if we know in advance how the subjectAltNames are
> ordered.

I agree it is not possible to do this automatically and perfectly for
every user and every certificate

I was simply aiming for something slightly less ambiguous than %fromcert

Using the @hostname notation - does that always do a local check that
the hostname is in the cert before sending it to the peer?  If so, that
is probably sufficient for most people who have multiple hostnames in a cert

Let's say my certificate has:

DN="C=AU, O=Example Pty Ltd, CN=host1.example.org"
subjectAltName=host1.example.org

The %fromcert directive isn't something that a new user can instantly
recognise and understand the way the ID is selected.  If the casual
IPsec admin comes across this:

leftid=%x509_dn,%x509_san

he is going to have a much more unambiguous understanding of what happens.

In fact, %x509_dn,%x509_san would always try DN first and if that fails
authentication, it would try SAN only if SAN exists in the cert

%x509_san,%x509_dn would be the opposite: if no SAN exists, it would
immediately try using the DN as the ID

Of course, all of that is based on the presumption that it is polite for
charon to try multiple auth attempts against the peer.

In the case of multiple SAN values, %x509_san could make a best effort
attempt to find a unique match (e.g. by testing each hostname against
the selected interface IP) and if it doesn't identify a unique match it
can give a local error.

The benefit of all this is that the user is much more likely to get a
meaningful error locally rather than just "authentication failed"

I've had a few cases where I had to go and check the logs in the peer to
understand that the ID was mismatched and I can imagine that will be
frustrating for people, especially in cases where they don't have
control over the peer or where they want to undertake a gradual
migration from one ID scheme to another.

Regards,

Daniel