| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
As with ike-init we can't return NULL in the task constructor.
|
|
|
|
|
|
| |
Returning FAILED in the constructor is wrong, but returning NULL doesn't work
either as it's currently assumed tasks always can be created.
Therefore, delay this check until we actually try to allocate a nonce.
|
| |
|
|
|
|
|
|
|
| |
This allows to control the life-cycle of a nonce in the context of the
ike init task. In the TKM use-case the nonce generator cannot be
destroyed before the ike init task is finalized, otherwise the created
nonce is detected as stale.
|
|
|
|
|
|
|
|
| |
This allows to control the life-cycle of a nonce in the context of the
child create task. In the TKM use-case, it is required to reset the
nonce context if the created nonce is not consumed. This happens if the
child SA negotiation fails and it is detected before the SA is
established via the TKM kernel plugin (i.e. rekey collision).
|
|
|
|
|
| |
The parameter indicates if the alert is raised upon failure to establish
the first CHILD SA of an IKE SA.
|
| |
|
| |
|
|
|
|
|
|
| |
Real AEADs directly provide a suitable IV generator, but traditional crypters
do not. For some (stream) ciphers, we should use sequential IVs, for which
we pass an appropriate generator to the AEAD wrapper.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
While such a change is not unproblematic, keeping status_t makes the API
inconsistent once we introduce return values for the public value operations.
|
|
|
|
|
|
| |
If additional tasks get queued before/while rekeying an IKE_SA, these get
migrated to the new IKE_SA. We previously did not trigger initiation of these
tasks, though, leaving the task unexecuted until a new task gets queued.
|
|
|
|
|
|
|
|
|
| |
We are actually not in rekeying state, but just trigger a separate, new IKE_SA
as a replacement for the current IKE_SA. Switching to the REKEYING state
disables the invocation of both IKE and CHILD_SA updown hooks as initiator,
preventing the removal of any firewall rules.
Fixes #885.
|
|
|
|
| |
functions
|
|
|
|
|
|
| |
Previously, we failed without recovery if a private key did not support
a selected signature scheme (based on key strength and the other peer's
supported hash algorithms).
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If this is disabled the schemes configured in `rightauth` are only
checked against signature schemes used in the certificate chain and
signature schemes used during IKEv2 are ignored.
Disabling this could be helpful if existing connections with peers that
don't support RFC 7427 use signature schemes in `rightauth` to verify
certificate chains.
|
|
|
|
|
| |
This is really just a fallback to "classic" IKEv2 authentication if the other
peer supports no stronger hash algorithms.
|
|
|
|
|
| |
By enumerating hashes we'd use SHA-1 by default. This way stronger
signature schemes are preferred.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This enables late connection switching based on the signature scheme used
for IKEv2 and allows to enforce stronger signature schemes.
This may break existing connections with peers that don't support RFC 7427
if signature schemes are currently used in `rightauth` for certificate chain
validation and if the configured schemes are stronger than the default used
for IKE (e.g. SHA-1 for RSA).
|
|
|
|
| |
This is mostly for testing.
|
|
|
|
|
|
| |
We use the new signature authentication instead for this. This is not
backward compatible but we only released one version with BLISS support,
and the key format will change anyway with the next release.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The previous code allowed an attacker to slip in an IKE_SA_INIT with
both SPIs and MID 1 set when an IKE_AUTH would be expected instead.
References #816.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts 8f727d800751 ("Clean up IKE_SA state if IKE_SA_INIT request
does not have message ID 0") because it allowed to close any IKE_SA by
sending an IKE_SA_INIT with an unexpected MID and both SPIs set to those
of that SA.
The next commit will prevent SAs from getting created for IKE_SA_INIT messages
with invalid MID.
Fixes #816.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Under some conditions it can happen that the CREATE_CHILD_SA exchange for
rekeying the IKE_SA initiated by the peer is successful, but the delete message
does not follow. For example if processing takes just too long locally, the
peer might consider us dead, but we won't notice that.
As this leaves the old IKE_SA in IKE_REKEYING state, we currently avoid actively
initiating any tasks, such as rekeying or scheduled DPD. This leaves the IKE_SA
in a dead and unusable state. To avoid that situation, we schedule a timeout
to wait for the DELETE message to follow the CREATE_CHILD_SA, before we
actively start to delete the IKE_SA.
Alternatively we could start a liveness check on the SA after a timeout to see
if the peer still has that state and we can expect the delete to follow. But
it is unclear if all peers can handle such messages in this very special state,
so we currently don't go for that approach.
While we could calculate the timeout based on the local retransmission timeout,
the peer might use a different scheme, so a fixed timeout works as well.
Fixes #742.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As we now use the same reqid for multiple CHILD_SAs with the same selectors,
having marks based on the reqid makes not that much sense anymore. Instead we
use unique marks that use a custom identifier. This identifier is reused during
rekeying, keeping the marks constant for any rule relying on it (for example
installed by updown).
This also simplifies handling of reqid allocation, as we do not have to query
the marks that is not yet assigned for an unknown reqid.
|
| |
|
| |
|
| |
|
|
|
|
| |
pki tool
|
| |
|