Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-27T22:49:58Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3133Read TSIG secret from file2024-03-27T22:49:58ZIulian MegheaRead TSIG secret from file---
name: Feature request
about: Suggest an idea for this project
---
Allow reading tsig-keys (at least the secret) from an external file. This way it can integrate better with secret management tools.
For example the configuration cou...---
name: Feature request
about: Suggest an idea for this project
---
Allow reading tsig-keys (at least the secret) from an external file. This way it can integrate better with secret management tools.
For example the configuration could use more relaxed permissions but the file containing the tsig secret can use very restrictive permissions.kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3024Post audit: Write KB article/ARM section about securing DB connection2023-09-21T10:10:03ZTomek MrugalskiPost audit: Write KB article/ARM section about securing DB connectionAs pointed out in [@manu's audit](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#12-secure-db-connection), we should have a kind of tutorial or step by step guide how to secure Kea and MariaDB/Postgres connect...As pointed out in [@manu's audit](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#12-secure-db-connection), we should have a kind of tutorial or step by step guide how to secure Kea and MariaDB/Postgres connection.
I think this would be best achieved by having a config example in the ARM + a KB article explaining how to do the changes in Maria/Postgres installations.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3021Post audit: update ARM to show how to confirm source code integrity2023-09-21T10:09:54ZTomek MrugalskiPost audit: update ARM to show how to confirm source code integrityAnother proposal by [@manu's audit](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#10-remote-administrative-access-authentication-restful-api). We should document how to check the integrity of the source code ...Another proposal by [@manu's audit](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#10-remote-administrative-access-authentication-restful-api). We should document how to check the integrity of the source code (and packages, too).
With the SBOM being increasingly focused, this is an important aspect. Fortunately, it's very easy doc update.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3020Post audit: investigate if basic auth with http could be discouraged2023-09-21T10:09:47ZTomek MrugalskiPost audit: investigate if basic auth with http could be discouragedAnother [report by @manu](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#10-remote-administrative-access-authentication-restful-api). The overall idea is to strongly discourage people from running basic auth o...Another [report by @manu](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#10-remote-administrative-access-authentication-restful-api). The overall idea is to strongly discourage people from running basic auth over plain HTTP. It's insecure, but maybe in some experiments it might be useful, so we probably shouldn't forcibly abort.
But perhaps print a warning with a link to ARM section explaining why it's wrong would do?next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2495Kea uses predictable filenames for sockets in /tmp2023-07-05T10:39:19ZParide LegoviniKea uses predictable filenames for sockets in /tmpDebian maintainer of the Kea package here; this is a forward of Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014929 and Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/isc-kea/+bug/1863100.
---
The default Kea con...Debian maintainer of the Kea package here; this is a forward of Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014929 and Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/isc-kea/+bug/1863100.
---
The default Kea configuration files place control sockets under `/tmp`, e.g.:
```
+---
| "control-socket": {
| "socket-type": "unix",
| "socket-name": "/tmp/kea4-ctrl-socket"
| },
+---[ /etc/kea/kea-dhcp4.conf ]
```
This can be a security issue, especially given that the socket have fixed names, as any use can create a file/socket with that name under `/tmp`. Please move the control sockets to `/run/kea`. Thanks!next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3023Implement RFC3118: DHCPv4 authentication2023-09-21T10:10:23ZTomek MrugalskiImplement RFC3118: DHCPv4 authenticationAs pointed out by [@manu's audit](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#14-support-authentication-in-dhcpv4-protocol), we should implement RFC3118 (DHCPv4 authentication).As pointed out by [@manu's audit](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#14-support-authentication-in-dhcpv4-protocol), we should implement RFC3118 (DHCPv4 authentication).backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2697if require-client-certs is false than cert-file and key-file should not be ne...2023-02-22T14:42:36Zjbbjarnasonif require-client-certs is false than cert-file and key-file should not be necessary---
name: Feature request
about: Suggest an idea for this project
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version? _No, I am running version `2.2.0-isc20220726061131`_
- A...---
name: Feature request
about: Suggest an idea for this project
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version? _No, I am running version `2.2.0-isc20220726061131`_
- Are you sure what you would like to do is not possible using some other mechanisms? _It is possible but wrong._
- Have you discussed your idea on kea-users or kea-dev mailing lists? _No_
**Is your feature request related to a problem? Please describe.**
If you configure `require-client-certs` as false in high availability hooks, you should not be required to declare `cert-file` and `key-file`
It is very important to describe what you would like to do and why?
Why? It doesn't make sense for remote Kea server to require client certificate from other Kea server when it is already configured as non-required.
**Describe the solution you'd like**
A clear and concise description of what you want to happen.
**Example config**
From high availability hook,
```json
"peers": [
{
"auto-failover": true,
"name": "kea-dhcpremote-2.kea-dhcpremote.default.svc.cluster.local.",
"role": "primary",
"url": "http://10.244.0.7:8000/"
},
{
"auto-failover": true,
"cert-file": "/certs/kea-client.crt",
"key-file": "/certs/kea-client.key",
"name": "kea-dhcpremote-1.kea-dhcpremote.default.svc.cluster.local.",
"require-client-certs": false,
"role": "standby",
"trust-anchor": "/certs/ca.crt",
"url": "https://10.244.0.5:8000/"
},
{
"auto-failover": true,
"name": "kea-dhcpremote-0.kea-dhcpremote.default.svc.cluster.local.",
"role": "backup",
"url": "http://10.244.0.10:8000/"
}
]
```
From the above config snippet, the `cert-file` and `key-file` should not be needed.
**Describe alternatives you've considered**
The alternative is to generate a bogus client certificate file and client key file and point to it, **Note** the files do not need to be the correct ones since it is not used.
**Additional context**
Add any other context about the feature request here.
**Funding its development**
Kea is run by ISC, which is a small non-profit organization without any government funding or any permanent sponsorship organizations. Are you able and willing to participate financially in the development costs? _No sorry_
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature as generic as possible, so it can be used in wide variety of situations. That means the proposed solution may be a bit different that you initially thought. Are you willing to take part in the design discussions? Are you willing to test an unreleased engineering code? _I would have to ask my employer_
**Contacting you**
How can ISC reach you to discuss this matter further? If you do not specify any means such as e-mail, jabber id or a telephone, we may send you a message on github with questions when we have them.
_jon.bjarni@menandmice.com_backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2300Deploy flawfinder in CI (SAST)2022-11-02T15:10:41ZTomek MrugalskiDeploy flawfinder in CI (SAST)There's [flawfinder](https://github.com/david-a-wheeler/flawfinder) tool that supposedly is useful for C/C++ code audit. We should:
1. [ ] try it and see if the results produced are useful
2. [ ] fix the problems it reported
3. [x] depl...There's [flawfinder](https://github.com/david-a-wheeler/flawfinder) tool that supposedly is useful for C/C++ code audit. We should:
1. [ ] try it and see if the results produced are useful
2. [ ] fix the problems it reported
3. [x] deploy it on CI
Each step depends on the previous one. If at any step we decide the whole thing doesn't make sense, the ticket should be closed.
It may be integrated with gitlab. Go to Security & Compliance -> Configuration, then Static Application Security Testing (SAST).backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2230Optionally put the database password in a file2023-08-21T14:05:56ZFrancis DupontOptionally put the database password in a fileExtension of #2006 to database configuration. With #34 aka database communication over SSL/TLS this will greatly improve security.Extension of #2006 to database configuration. With #34 aka database communication over SSL/TLS this will greatly improve security.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1971PRNG and pre-allocation2022-11-02T15:10:40ZFrancis DupontPRNG and pre-allocationI think the use of the std::mt19937 PRNG is a potentially security sensitive code should at least be analyzed.I think the use of the std::mt19937 PRNG is a potentially security sensitive code should at least be analyzed.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1903Assess Kea vs. NIST 'Zero trust architecture'2022-11-02T15:10:17ZVicky Riskvicky@isc.orgAssess Kea vs. NIST 'Zero trust architecture'Kea was designed for deployment into a protected environment in a datacenter. Although we are gradually adding more security features, we should do an assessment of which of the NIST Zero Trust architecture requirements we meet and which...Kea was designed for deployment into a protected environment in a datacenter. Although we are gradually adding more security features, we should do an assessment of which of the NIST Zero Trust architecture requirements we meet and which we do not and document that.
https://www.nist.gov/publications/zero-trust-architecturebackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1767check static analysers reports2022-11-02T15:10:18ZWlodzimierz Wencelcheck static analysers reportsRecent increased interest in security reminded me that it was some time since anyone looked into our static analysers, reports are:
* https://scan.coverity.com/projects/kea/view_defects (if you don't have an account please sign in and re...Recent increased interest in security reminded me that it was some time since anyone looked into our static analysers, reports are:
* https://scan.coverity.com/projects/kea/view_defects (if you don't have an account please sign in and request access to kea)
* https://jenkins.isc.org/view/All/job/kea-master-cppcheck-internal/
We need:
* review reports
* in coverity mark issues with correct status
* open tickets for real issues
* fix issues :)backlogRazvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1764Remove massive duplication in http/tls tests code2022-11-02T15:10:17ZTomek MrugalskiRemove massive duplication in http/tls tests codeThe !1116 branch introduced TLS socket and tests. The tests reused existing HTTP tests, which caused massive code duplication. The goal of this ticket is to remove duplication between the following files:
- tls_client_unittests.cc
- tls...The !1116 branch introduced TLS socket and tests. The tests reused existing HTTP tests, which caused massive code duplication. The goal of this ticket is to remove duplication between the following files:
- tls_client_unittests.cc
- tls_server_unittests.cc
- server_client_unittests.cc
See comments https://gitlab.isc.org/isc-projects/kea/-/merge_requests/1116#note_200522 and https://gitlab.isc.org/isc-projects/kea/-/merge_requests/1116#note_200526.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1756Consider signing up Kea for the free Google OSS-fuzz scanning program2022-11-02T15:10:20ZVicky Riskvicky@isc.orgConsider signing up Kea for the free Google OSS-fuzz scanning programYou add your project to the google oss-fuzzing project by submitting a pull request. We did this for BIND. It uses multiple fuzzers, and I think in the case of BIND, we were already running all but one of these in house. They don't publi...You add your project to the google oss-fuzzing project by submitting a pull request. We did this for BIND. It uses multiple fuzzers, and I think in the case of BIND, we were already running all but one of these in house. They don't publish your bugs right away, but report them to the project privately first, so you can fix them before they are published.
https://github.com/google/oss-fuzz/tree/master/projectsbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/873Integrate CodeQL (LGTM replacement) security checker into our process2023-02-23T12:30:30ZTomek MrugalskiIntegrate CodeQL (LGTM replacement) security checker into our processThere's a tool called LGTM: https://lgtm.com/
It is advertised as a security checker and is free for open source projects.
@manu, @fdupont, @godfryd - have you ever used it? Any opinions?
UPDATE: LGTM was replaced with CodeQL.There's a tool called LGTM: https://lgtm.com/
It is advertised as a security checker and is free for open source projects.
@manu, @fdupont, @godfryd - have you ever used it? Any opinions?
UPDATE: LGTM was replaced with CodeQL.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/350Ability to send DHCPv6 Reconfigure message2023-09-21T10:10:36ZTomek MrugalskiAbility to send DHCPv6 Reconfigure messageThis is a migration of [issue #84](https://github.com/isc-projects/kea/issues/84) from github.
The goal of this ticket is to implement capability to send reconfigure message. This at the very least requires implementing a "reconfig-send...This is a migration of [issue #84](https://github.com/isc-projects/kea/issues/84) from github.
The goal of this ticket is to implement capability to send reconfigure message. This at the very least requires implementing a "reconfig-send" command, and the actual ability to retrieve lease from db and then send reconfigure message with authentication option.
Here's [one request for it](https://lists.isc.org/pipermail/kea-users/2020-October/002910.html).backlog2020-02-29https://gitlab.isc.org/isc-projects/kea/-/issues/1794TLS shutdown2022-05-30T11:29:08ZFrancis DupontTLS shutdownRelated to #1661 and #1706: TLS has a notion of orderly named TLS shutdown we can use or not.Related to #1661 and #1706: TLS has a notion of orderly named TLS shutdown we can use or not.outstanding