[Swan-dev] Question PSK Asymmetric Patch

[Paul Wouters]

On Wed, 10 Jun 2020, c.mailer at grad.ufsc.br wrote:

> What would I need to change to add support for asymmetric PSK authentication on Libreswan?

There are two aspects to this.

1) How do we specify this in our secrets file ?

2) How we do implement 1)


The biggest question is 1)

Currently, secrets are tied to IDs, so if you have:

conn test
 	leftid=@foo
 	rightid=@bar
 	authby=secret
 	[...]

Your secrets file will have:

@foo @bar : PSK "secret"

you can omit an ID and it will become a wildcard, eg:

: PSK "secret"

or:

@vpnserver %any: PSK "secret"


So we could look at extending the syntax. Possibly:

@foo @bar : PSK "secret1" "secret2"

But what would that mean, @foo identies using "secret1" ? or @foo
requiring from @bar "secret1".

So perhaps it would be better to use:

@foo : PSK "secret1"
@bar : PSK "secret2"

But currently, the code would look up our own id (eg @foo) and pick that
secret, and not look at the remote id.


Also, if you have two conns for which you use id @foo, eg one to @bar
and one to @zzz, which use different secrets for you, then you need
to bind the secrets to use to both IDs, so this latter one would not
help.

We could add a new secret type, eg APSK that takes two secrets, eg

@foo @bar : APSK "secret1" "secret2"
@foo @zzz : APSK "secret3" "secret4"


And perhaps try to patch APSKs before PSKs to that the wildcards
won't match before asymmetric PSKs, eg when using:

@foo : PSK "secret1"
@foo @bar : APSK "secret1 secret2"


But, there is an additional potential problem.

What if we do not yet know the remote id? We send our AUTH
payload in IKE_AUTH before receiving the remote ID in their IKE_AUTH
reply. Usually, if you don't know the remote ID it is because it is
packet triggered, but usually those cannot really use PSK anyway. Or
because it is CERT based, and then you don't use PSK.

So perhaps the new APSK keyword would work?


Then we have 2)
Who is going to change the code in lib/libswan/secrets.c and programs/pluto/ikev2_parent.c


The reason I think this entire endavour is a bit silly is that both ends
need to know both PSKs. What security is gained by using two seperate
PSKs over using one symmetric PSK ?

Paul