Libreswan Documentation

Logo

Libreswan's Online Documentation

View the Project on GitHub libreswan/libreswan.github.io

Support
FAQ Common Error Messages
History
Implemented Standards
Kernel Support
HOWTO Additional ipsec.conf documentation
AWS Mesh
brendans Road Warrior Setup at Home
Configuration examples
Confuse !?@: github wiki
Enterprise cloud encryption
Entropy matters
EoIP shared ethernet LAN using IPsec
High Availability Fallover VPN in AWS
Host to host VPN
Host to host VPN with PSK
Libreswan as client to a Cisco ASA or VPN3000 server
Microsoft Azure configuration
Migrate from IKEv1 DPD to IKEv2 LIVENESS
Opportunistic IPsec
Opportunistic IPsec using LetsEncrypt
Pluto and DNSSEC
Read status output
Route based VPN
SElinux and Labeled IPsec VPN
Subnet extrusion
Subnet to subnet using NAT
Subnet to subnet VPN
Subnet to subnet VPN with PSK
Unauthenticated Opportunistic IPsec
Using Apache to serve PKCS
Using NSS Hardware Tokens
Using NSS with libreswan
VPN server for remote clients using IKEv2
VPN server for remote clients using IKEv2 split VPN
GSoC 2027 Code Project Ideas DRAFT
Contributor Guidance DRAFT
Completed Projects 2026 RFC 9593 Announcing Supported Authentication Methods in IKEv2
2026 Improve the ACQUIRE to IKE policy lookup
2026 Add HOST TO HOST Support on BSD
2021 RFC 8420 Add EdDSA Signature Authentication Support to IKEv2
2020 Session Resumption
2020 IKEv2 Interop testing with OpenBSD
2020 IKE Intermediate Exchange
2019 Libreswan Opportunistic IPsec using LetsEncrypt
2018 RSA PSS Support in compliance with RFC 7427 and RFC 8247
2018 RFC 7427 Add ECDSA Signature Authentication Support to IKEv2
2018 RFC 5685 Redirect Mechanism
2018 Managing Interface
2017 TCP encapsulation of IKE and IPsec
2017 RFC 7427 Add Signature Authentication Support to IKEv2
2017 Postquantum Preshared Keys
Presentations
IRC
Hacking Documentation
Git, GitHub, and Pull Requests
Merging GitHub Pull Requests
Programming Conventions
Testing Docker
KVM 1. Setup The Host
2. Configure Testing
3. Compile Libreswan
4. Test Libreswan
5. Accessing The Console
6. Maintenance and Internals
Bisecting
Debugging Pluto
Logging In Using SSH
Performance
Running A Custom Kernel
Running A Single Test
Running In The Background
Setup a Web Server
Testing Old Branches
Updating Test Results
Namespace Magic
Namespaces
Topology
Internals 3.14 X509
Benchmarking and Performance testing
Cipher suites and algorithm support
Cloud OE ideas
Compiling with AddressSanitizer
Compliance of RFC 7427 Signature Authentication in IKEv2
Coverity
Cryptographic Acceleration
Developer links strongswan android
Discouraged or forbidden C functions
IKEv2 Child SA
IKEv2 CP and EAP support
Introduction
Libreswan xfrm kernel support
Logging cleanup
New OE
Pluto
Pluto packet processing
Proposed ipsec ca command
Retransmit timings
Road Map
SAref code
Setting up system for debug logging
stf status
Testing 2017 Next Generation
Unbound
Uncrustify
Use Cases and Requirements document for ECC ECDSA support
Use Cases and Requirements document
XFRM Interface Development Notes
XFRM pCPU
XFRM pCPU RSS
Security Crypto boundary and certification
Libreswan and Heartbleed
Libreswan and TunnelCrack
Reporting a Vulnerability
Vulnerabilities
Meetups 2013 Helsinki
2014 San Francisco
2014 Toronto
2018 Toronto
Obsolete HOWTOs IKEv1 XAUTH with FreeOTP and FreeIPA
IKEv1 XAUTH with Google Authenticator One Time Passwords
Route based VPN using VTI
Testing Namespace
VPN server for remote clients using IKEv1 with L2TP
VPN server for remote clients using IKEv1 XAUTH with Certificates
VPN server for remote clients using IKEv1 XAUTH with PSK

Introduction

Prior to RFC 7427, the Internet Key Exchange version 2 (IKEv2) signature based authentication is signaled per algorithm i.e., there is one Authentication Method for RSA digital signatures, one Authentication Method for DSS digital signatures (using SHA-1), and three separate Authentication Methods for the different ECDSA curves with each variant tied to exactly one hash algorithm. This leads to two problems:

Therefore this design is cumbersome when more signature algorithms, hash algorithms, and elliptic curves need to be supported.

RFC 7427 solves these problems by generalising the IKEv2 signature support to allow any signature method supported by PKIX and also adds a signature hash algorithm negotiation. RFC 7427 defines a new “Digital Signature Authentication” method. This method is flexible to include all current signature methods (RSA, DSA, ECDSA, RSASSA-PSS, etc.) and add new methods (ECGDSA, ElGamal, etc.) in the future.

The libreswan implementation of RFC 7427 is included in version 3.22. RFC 7427 based Digital Signatures is automatically enabled if the “authby” parameter in ipsec.conf is configured to use RSA and it has received SHA-1 in the Hash Algorithm notification payload from the peer indicating that the remote peer supports this method as well.

Implementation

To make Libreswan RFC 7427 compliant, the following items have been implemented :

1. Hash Algorithm Notification

Notify payload of type SIGNATURE_HASH_ALGORITHMS is sent inside the IKE_SA_INIT exchange. The supported hash algorithms like SHA1, SHA2 and IDENTITY are exchanged by the initiator and responder in this notify payload. The negotiated hash algorithm is the one that is supported by both parties. This hash algorithm is used to generate the signature sent in the Authentication payload. The decision of sending the Hash Algorithm notification when Libreswan is the initiator is based on checking which Signature algorithm is configured in the “authby” parameter in ipsec.conf. When Libreswan is the responder, it responds with a hash algorithm notification only if it has received one and SHA-1 was sent in it.

2. Authentication payload

A new Authentication Method called Digital Signature is sent in the IKE_AUTH message exchange. Earlier, the Authentication Data field inside the Authentication payload contained only the signature value. Now, the signature value is prefixed with an ASN.1 object indicating the algorithm used to generate the signature. The ASN.1 object contains the algorithm identification OID, which identifies both the signature algorithm and the hash algorithm used for calculating the signature. IANA registry specifies the values to be used. The initial Digital Signature Authentication method implementation for Libreswan only includes support for the RSA with SHA-1 hash algorithm.

The following items are not yet implemented :

3. Test Suite changes

The Test Suite was extended by adding test cases to verify feature functionality and perform interoperability tests. Negative tests cases were added using impairments that emulate clients that do not support the Digital Signature Authentication scheme as specified by the RFC 7427, to confirm connectivity with clients not supporting the new Authentication Method.

Issues encountered

The RFC 4307bis mandates the usage of RSASSA-PSS along with Digital Signature Authentication. However the older flavour PKCS v1.5 may still be supported. But a way to indicate to the peer, which flavour of RSA should be used is not yet described. Since no other client supports RSASSA-PSS, interoperability tests cannot be performed.

Future work

Implementation of ECDSA requires the extension of the Libreswan’s public key code to remove the hardwiring for RSA. Implementation of RSASSA-PSS would have to use different NSS library method call. The implementation is waiting for RFC 4307bis to clarify the usage of PSS.

SHA2 needs an extended parser for the authby = keyword, in ipsec.conf.

Source code

Feature implementation

Addition and modification of test cases

This project work was sponsored by Google as part of the Google Summer of Code 2017 Program. The implementation for this project is done by Sahana Prasad (sahana.prasad07@gmail.com) under the tutelage of Paul Wouters.