ipsec: add some authentication documentation#885
Conversation
AdSchellevis
left a comment
AdSchellevis
left a comment
There was a problem hiding this comment.
I'm interested in @Monviech view on this, it might help adding some context about authentication, but might still need some work. Still struggling a bit with the rest of the section, we might consider removing (or moving) legacy at some point as well to make this section more readable.
The complication probably is to explain the common pitfalls without risking the need to copy all strongswan's documentation.
| **Remote authentication** defines how the peer is expected to authenticate itself to this system. | ||
|
|
||
| Each authentication entry has an ID, the ID is important because it is the identity presented or expected | ||
| during IKE authentication. It is also used to select matching credentials, such as pre-shared keys or public keys. |
There was a problem hiding this comment.
From the help text/swanctl documentation:
IKE identity to use for authentication round. When using certificate authentication the IKE identity must be contained in the certificate; either as the subject DN or as a subjectAltName (the identity will default to the certificate’s subject DN if not specified). Refer to https://docs.strongswan.org/docs/5.9/config/identityParsing.html for details on how identities are parsed and may be configured.
Maybe we should mention certificate matching here briefly was well.
| it's generally recommended to explicitly set all ID values in the connection local/remote authentication, | ||
| as well as the local/remote IDs of the pre-shared keys or local IDs for key-pairs. Leaving these empty | ||
| will often default to the local IP on the local side and :code:`%any` for the remote side. This means | ||
| that if you have PSKs linked to your local IP, these are elligible to be used for other connections |
There was a problem hiding this comment.
I think pre-shared keys are a bit of an odd duck here as they come with their own identifiers which should match (by pattern), where keypairs are simply matched by their public key (and ids are only used to match the connection).
When it comes to roadwarriors, remote is almost always set to %any (blank) as far as I know.
|
I have no strong feelings for or against this section. It's very general, I don't know how helpful it can be, since ipsec is like a cookbook with thousands of recipes and a lot of vendor quirks. Generally speaking, I prefer using the strongswan documentation since it's also kept up to date with how the strongswan daemon itself evolves over time. I would also vet for removing the legacy IPsec guides and streamline the main document a bit more. Maybe better configuration examples help here in the line of: I did not see a lot of user pain around the authentication aspect so far, it's more that IPsec itself is quite complicated. |
|
I generally prefer how-tos to explain certain things, because that way there is an example already. Should we do one that also shows how to use certificates as an additional authentication round? Though then we would probably retrofit this into our documentation: And the examples there are way more diverse and better documented... hmm. |
3 participants
No description provided.