Linux-SCTP Archive mirror
 help / color / mirror / Atom feed
From: Adam Snaider <adam.snaider@bluerivertech.com>
To: Xin Long <lucien.xin@gmail.com>
Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
	linux-sctp@vger.kernel.org
Subject: Re: SCTP Authentication Current State and Examples
Date: Mon, 22 May 2023 16:21:50 -0700	[thread overview]
Message-ID: <CALP-OgmH8ZegbJDOj6QxXpNaLQT7cnRvBJzJ-67urfqMuWXe-w@mail.gmail.com> (raw)
In-Reply-To: <CADvbK_f=TLj0M7zuF+3sE+91R2c+waDA2t30MvdH7KU619qQYw@mail.gmail.com>

Ah that makes sense! Thank you

On Mon, May 22, 2023 at 12:58 PM Xin Long <lucien.xin@gmail.com> wrote:
>
> Hi, Adam,
>
> Thanks for the scripts.
>
> In SCTP, after 'sysctl net.sctp.auth_enable=1' and
> setsockopt(SCTP_AUTH_CHUNK), it will tell the peer that this side
> supports auth. Meanwhile, the kernel creates a 'null_key' (key_id = 0)
> as the default one.
>
> The peer uses the shared key (key_id = 0) for the auth chunk if it
> doesn't set up any key, like on your client side. On your server side,
> it added a new shared key (key_id = 1), but the server still can
> process the incoming auth chunk with the shared key (key_id = 0), even
> if it's not the active key,  unless you deleted the shared key (key_id
> = 0).
>
> Just note that it's the peer's choice which sh_key it will use, and it
> uses key_id = 0 by default. If you want the authentication to fail in
> your case, try to delete the shared key (key_id = 0) after you set up
> the new one (key_id = 1):
>
>         authkeyid.scact_keynumber = 0;
>         ASSERT(setsockopt(fd, IPPROTO_SCTP, SCTP_AUTH_DELETE_KEY,
> &authkeyid, sizeof(authkeyid)) == 0,
>                "fail to del key");
>
> Make sense?
>
> Thanks.
>
> On Mon, May 22, 2023 at 1:52 PM Adam Snaider
> <adam.snaider@bluerivertech.com> wrote:
> >
> > Hi Marcelo,
> >
> > Thank you for your response. The issue I'm facing is that if I set up a server with authentication using some random key, then I'm still able to receive data from a client that didn't set up the shared key itself. However, if the client also sets up authentication but the key is incorrect, then the server refuses the message and it tries again (which is similar to what I would expect).
> > The code I'm using is here: https://gist.github.com/brt-adam-snaider/3076ab06f846384f5a7f87ad54ddd276, where the server calls `Bind` and the client calls `Unbound` to create their respective sockets. (Note how I purposely only set up the authentication key in the `Bind` call). Running tcpdump however, I can see that there are authenticated chunks being sent (since the chunk type is 0xf), so I'm not sure why the server is receiving those without errors.
> >
> > Thank you for the help! And for what it's worth, I would love to contribute some documentation once I'm done working with this :)
> >
> > Best,
> > Adam
> >
> >
> > On Fri, May 19, 2023 at 6:09 PM Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote:
> >>
> >> On Mon, May 15, 2023 at 12:00:00PM -0700, Adam Snaider wrote:
> >> > Hi folks,
> >> >
> >> > I would like to ask what the current state is for SCTP Authentication
> >> > in the Linux kernel (as described by rfc4895). I've been attempting to
> >> > use an SCTP authenticated socket in the 5.10 kernel but all my efforts
> >> > are fruitless so far. Given the lack of examples around, I'm not sure
> >> > if my setup is incorrect or if the linux implementation is incomplete.
> >> > If there are any references or examples I can look at I would really
> >> > appreciate it.
> >>
> >> Hi Adam,
> >>
> >> The support should be complete, but yeah, I am not aware of examples
> >> with Auth. Would you mind sharing a minimal reproducer that didn't
> >> work for you?
> >>
> >> Thanks,
> >> Marcelo

      reply	other threads:[~2023-05-23  0:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-15 19:00 SCTP Authentication Current State and Examples Adam Snaider
2023-05-20  1:08 ` Marcelo Ricardo Leitner
     [not found]   ` <CALP-OgntP2Tj3H_GK0ZODa95gJb5NnLt26O0YPkgx4VsMF-Yqg@mail.gmail.com>
2023-05-22 19:57     ` Xin Long
2023-05-22 23:21       ` Adam Snaider [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALP-OgmH8ZegbJDOj6QxXpNaLQT7cnRvBJzJ-67urfqMuWXe-w@mail.gmail.com \
    --to=adam.snaider@bluerivertech.com \
    --cc=linux-sctp@vger.kernel.org \
    --cc=lucien.xin@gmail.com \
    --cc=marcelo.leitner@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).