Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Struct names and members for secrets.conf (Julien ?LIE)
2. Re: Struct names and members for secrets.conf (Russ Allbery)
3. Re: Struct names and members for secrets.conf (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Mon, 27 Dec 2021 17:41:26 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Struct names and members for secrets.conf
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Russ,
>> we may probably want a general program for that, and not a dedicated
>> one for each configuration file...
>> Why not add a -f flag (for "file") to innconfval? Default value is
>> "inn.conf", and it can be set to other file names (like "secrets.conf").
>
> That's a good idea!
It may be useful. I'll see what I can do.
Speaking of file names, I'm wondering whether "inn.secrets" wouldn't be
better. I remember we once had to change radius.conf to inn-radius.conf
(as the radius program already exists); secrets.conf is a general name
that may be used by other programs, so maybe inn.secrets(5) will be
better for the man page and the file name.
>> Not all secrets are strings. Here, for canlockadmin, it is a vector.
>> So maybe we need get_secret_list(secrets, "cancels", "canlockadmin") and
>> another get_secret_string() function for future string secrets?
>
> Oh, good point, I hadn't thought about that. I'm not entirely sure the
> additional complexity is worth it (your approach looked fine). We can
> always wait and see if that would be a simplification.
We could have both approaches:
- secrets->canlockadmin (or innsecrets->canlockadmin which would be a
good name too if we have inn.secrets) and other (inn)secrets->xxx
variables for all secrets that are defined only once in the secrets.conf
file;
- get_secret_string() or other similar functions for any secrets that
may appear several times at different scopes of the file. And we'll see
how to do that when it happens.
--
Julien ?LIE
??Medicorum nutrix est intemperantia.??
------------------------------
Message: 2
Date: Mon, 27 Dec 2021 08:48:18 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Struct names and members for secrets.conf
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> It may be useful. I'll see what I can do.
> Speaking of file names, I'm wondering whether "inn.secrets" wouldn't be
> better. I remember we once had to change radius.conf to inn-radius.conf
> (as the radius program already exists); secrets.conf is a general name
> that may be used by other programs, so maybe inn.secrets(5) will be
> better for the man page and the file name.
inn-secrets.conf is what I'd go with, keeping the period for the file type
extension. That's a good call; I was thinking it wouldn't matter because
we're installing it in our own private configuration directory, but if it
has its own man page, secrets.conf is a very generic name.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 3
Date: Mon, 27 Dec 2021 17:56:12 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Struct names and members for secrets.conf
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Russ,
>> It may be useful. I'll see what I can do.
>> Speaking of file names, I'm wondering whether "inn.secrets" wouldn't be
>> better. I remember we once had to change radius.conf to inn-radius.conf
>> (as the radius program already exists); secrets.conf is a general name
>> that may be used by other programs, so maybe inn.secrets(5) will be
>> better for the man page and the file name.
>
> inn-secrets.conf is what I'd go with, keeping the period for the file type
> extension. That's a good call; I was thinking it wouldn't matter because
> we're installing it in our own private configuration directory, but if it
> has its own man page, secrets.conf is a very generic name.
Yes, I plan on adding a man page. Here follows what I have already come up
with.
OK for inn-secrets.conf.
=head1 NAME
inn-secrets.conf - Configuration data for InterNetNews secrets
=head1 DESCRIPTION
F<inn-secrets.conf> in I<pathetc> is a configuration file containing general
secrets used by INN. It was added in S<INN 2.7.0> for the implementation of
Cancel-Lock. The intent is that new secrets used by INN are added to that
file, and that all secrets currently stored in several other configuration
files eventually move to that file.
The F<inn-secrets.conf> file is not required. It currently only serves
the purpose of Cancel-Lock. If not present or empty, the Cancel-Lock
authentication system will just be deactivated for local posts.
This file is intended to be fairly static. Any changes made to it will
generally not affect any running programs until they restart.
Changes in Cancel-Lock secrets will be taken into account when new
B<nnrpd> processes are spawned (which happens each time a reader opens a
new connection).
Blank lines and lines starting with a number sign (C<#>) are ignored.
All other lines specify parameters, and are organized in groups. The general
form is:
<group> {
<name>: <value>
}
(Any amount of whitespace can be put after the colon and is optional.) If the
value contains embedded whitespace or any of the characters C<< []<>{}"\:; >>,
it must be enclosed in double quotes (""). A backslash (C<\>) can be used
to escape quotes and backslashes inside double quotes. <group> and <name>
are case-sensitive; C<cancels> is not the same as C<Cancels> or C<CANCELS>.
(F<inn-secrets.conf> groups and parameters are generally all in lowercase.)
The two parameters currently defined in this file have as their value
a list of strings, that is to say space-separated elements enclosed in
square brackets. Examples follow in the documentation.
=head1 PARAMETERS
=head2 Cancel-Lock secrets
These secrets are used for the Cancel-Lock authentication system described
in S<RFC 8315>. This mechanism permits verifying that the withdrawal of an
article is valid, that is to say the poster, posting agent, moderator, or
injecting agent that processed the original article has requested to withdraw
it via the use of a cancel control article or a Supersedes header field.
You'll need to build INN with version 3.3.0 or later of libcanlock
to embed Cancel-Lock support. This library is available at
L<https://micha.freeshell.org/libcanlock/>.
The C<cancels> group is defined as follows:
cancels {
canlockadmin: [ "Cl4yniTtmlsR3nwVaM2erBQClVprEtLjd/UiqTErXjk=" ]
canlockuser: [ "tf+fY0Z7KNzYzF9uPo/qPrLKOPXIJLqejwqsV1nwOTRwGQ==" ]
}
If one of the I<canlockadmin> or I<canlockuser> parameters is not
an empty list, B<nnrpd> will add information to every posted article that
will permit other news servers to later ensure that an attempt to cancel
or supersede the article is not forged, and really originates from the
authenticated original sender or the administrator of the local server.
More concretely, for each secret in I<canlockadmin>, B<nnrpd> adds
two Base64-encoded hashes to a Cancel-Lock header field. These hashes
are based on the secret and the Message-ID of the article. If this field
already exists, it will just append the Base64-encoded hashes to its end.
One hash uses the SHA-1 algorithm (for interoperability reasons as not all
news software implement SHA-256), and the other hash uses the mandatory
SHA-256 algorithm per S<RFC 8315>. Besides, if the poster is authenticated,
B<nnrpd> will similarly add two Base64-encoded hashes for each secret in
I<canlockuser>. These hashes are based on the secret, the user name
and the Message-ID of the article.
When a cancel or supersede article is posted by an authenticated user,
B<nnrpd> will add to a Cancel-Key header field two pre-images for each
secret in I<canlockuser>. Other news servers can then hash one of these
pre-images with SHA-1 or SHA-256 algorithms (one is enough) and verify
that the resulted Base64-encoded hash is the same as the one present in the
Cancel-Lock header field of the original article. (Necessarily, the same
authenticated user on the same local server sent the original article.)
When receiving articles with a Cancel-Key header field (locally or from
other peers), B<innd> applies that check to verify the authenticity of the
withdrawal before deciding to honour it.
Naturally, no pre-images for each secret in I<canlockadmin> are added by
B<nnrpd>. As these pre-images are not based on a user name, only the news
administrator can generate them with a separate program (yet to write, and
that will be shipped with the final 2.7 release), and then inject the cancel
or supersede request with for instance B<inews>. The news administrator
is therefore capable to send authenticated withdrawal requests for articles
posted by all the users of his news server, be they authenticated or not.
After this (little) introduction to explain what Cancel-Lock is for, here
are the two relevant parameters:
=over 4
=item I<canlockadmin>
This parameter expects a list of strings. It is unset by default (no admin
hashes will be generated).
If this parameter is not an empty list, each provided secret will be used
to generate admin hashes.
To maximize security, secrets should have a length of at least the output
size of the hash function used (32 octets for SHA-256). You can for instance
generate a strong secret based on 36 random octets with:
% openssl rand -base64 36
Vs4zdggAHKEUtqs6dH5/oNGWwIVFPf2ZIngog6aE6cDMoyJF
and use it as follows:
canlockadmin: [ "Vs4zdggAHKEUtqs6dH5/oNGWwIVFPf2ZIngog6aE6cDMoyJF" ]
The purpose of providing several secrets is when you want to rotate secrets.
For instance, if your policy is to change secrets each year, you can use
two secrets during a transition period:
canlockadmin: [ "rH5L8geEzkNVvpAZQMJJcd4AYkpSkkx5S/4qewPDA/U="
"eAaeyrQfjqQryhqrfwJOKezwf9GpL+xs+A9YfK9MMxE=" ]
Withdrawals of previously posted articles will still work with the old
secret (still added to the Cancel-Key header field).
As all posted articles will have a Cancel-Lock header field, you should also
set I<canlockuser> because otherwise posters may not be able to withdraw
their own articles (unless their posting agents generate Cancel-Lock header
fields themselves).
=item I<canlockuser>
This parameter expects a list of strings. It is unset by default (no hashes
will be generated for authenticated users).
If this parameter is not an empty list, each provided secret will be used
to generate hashes for authenticated users.
The same recommendation of more than 32 random octets applies, and the
secrets must not be the same as I<canlockadmin>.
You should also set I<canlockadmin> because you may otherwise not always
be able to cancel an article posted by an authenticated user (if you do
not manage to find out the user name).
=back
=head1 HISTORY
Documentation written by Julien Elie for InterNetNews.
=head1 SEE ALSO
nnrpd(8).
--
Julien ?LIE
??Medice, cura te ipsum.??
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 136, Issue 10
********************************************
