| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
|
|
|
|
|
|
| |
If additional authentication constraints, such as group membership,
is not fulfilled by an XAuth backend, we search for another
peer configuration that fulfills all constraints, including those
from phase1.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
initiator
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
While Aggressive Mode PSK is widely used, it is known to be subject
to dictionary attacks by passive attackers. We don't complain as
initiator to be compatible with existing (insecure) setups, but
require a scary strongswan.conf option if someone wants to use it
as responder.
|
| |
|
|
|
|
|
| |
If a configuration is instanced more than once using narrowing,
we should keep all unique quick modes up during rekeying.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
If both peers initiate quick mode rekeying simultaneously, we end up
with duplicate SAs for a configuration. This can't be avoided, nor do
the standards provide an appropriate solution. Instead of closing one
SA immediately, we keep both. But once rekeying triggers, we don't
refresh the SA with the shorter soft lifetime, but delete it.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
responses
|