Message-ID: <20250823013922.Horde.J-H85jaVn6AHI0UeML3QS3m@webmail.uniroma2.it>
Date: Sat, 23 Aug 2025 01:39:22 +0200
From: Paolo Lungaroni <paolo.lungaroni@...roma2.it>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Andrea Mayer <andrea.mayer@...roma2.it>,
        Stephen Hemminger
 <stephen@...workplumber.org>,
        netdev@...r.kernel.org, David Ahern
 <dsahern@...il.com>,
        David Lebrun <dlebrun@...gle.com>, stefano.salsano@...roma2.it
Subject: Re: [PATCH iproute2-next v2] man8: ip-sr: Document that passphrase
 must be high-entropy

Eric Biggers <ebiggers@...nel.org> ha scritto:

> On Thu, Aug 21, 2025 at 12:07:43AM +0200, Andrea Mayer wrote:
>> On Wed, 20 Aug 2025 12:54:58 -0700
>> Stephen Hemminger <stephen@...workplumber.org> wrote:
>>
>> > On Wed, 20 Aug 2025 11:43:17 -0700
>> > Eric Biggers <ebiggers@...nel.org> wrote:
>> >
>> > > On Wed, Aug 20, 2025 at 09:25:35AM -0700, Stephen Hemminger wrote:
>> > > > On Fri, 15 Aug 2025 20:18:46 -0700
>> > > > Eric Biggers <ebiggers@...nel.org> wrote:
>> > > >
>> > > > > diff --git a/man/man8/ip-sr.8 b/man/man8/ip-sr.8
>> > > > > index 6be1cc54..cd8c5d18 100644
>> > > > > --- a/man/man8/ip-sr.8
>> > > > > +++ b/man/man8/ip-sr.8
>> > > > > @@ -1,6 +1,6 @@
>> > > > > -.TH IP\-SR 8 "14 Apr 2017" "iproute2" "Linux"
>> > > > > +.TH IP\-SR 8 "15 Aug 2025" "iproute2" "Linux"
>> > > >
>> > > > NAK - do not change man page date for each change.
>> > >
>> > > Sure, if that's the convention for this project.  Note that this differs
>> > > from the convention used by most projects with dated man pages.  The
>> > > purpose of the date is normally to indicate how fresh the man page is.
>> > >
>> > > > >  .SH "NAME"
>> > > > >  ip-sr \- IPv6 Segment Routing management
>> > > > >  .SH SYNOPSIS
>> > > > >  .sp
>> > > > >  .ad l
>> > > > > @@ -32,13 +32,21 @@ internal parameters.
>> > > > >  .PP
>> > > > >  Those parameters include the mapping between an HMAC key  
>> ID and its associated
>> > > > >  hashing algorithm and secret, and the IPv6 address to use  
>> as source for encapsulated
>> > > > >  packets.
>> > > > >  .PP
>> > > > > -The \fBip sr hmac set\fR command prompts for a passphrase  
>> that will be used as the
>> > > > > -HMAC secret for the corresponding key ID. A blank  
>> passphrase removes the mapping.
>> > > > > -The currently supported algorithms for \fIALGO\fR are  
>> \fBsha1\fR and \fBsha256\fR.
>> > > > > +The \fBip sr hmac set\fR command prompts for a  
>> newline-terminated "passphrase"
>> > > >
>> > > > That implies that newline is part of the pass phrase.
>> > >
>> > > Not really.  "NUL-terminated" strings don't include the NUL in the
>> > > string content.  If you prefer, it could be made explicit as follows:
>> > >
>> > >     The \fBip sr hmac set\fR command prompts for a "passphrase" that
>> > >     will be used as the HMAC secret for the corresponding key ID. The
>> > >     passphrase is terminated by a newline, but the terminating newline
>> > >     is not included in the resulting passphrase.
>> > >
>> > > But I don't think it's very useful, as it's not needed to know how to
>> > > use the command correctly.
>> > >
>> > > > The code to read password is using getpass() which is marked  
>> as obsolete
>> > > > in glibc. readpassphrase is preferred.
>> > >
>> > > Is that relevant to this documentation patch?
>> > >
>> > > > > +that will be used as the HMAC secret for th
>> >
>> > Since this is only part of iproute2 that uses getpass() probably should
>> > be rethought. Having key come from terminal seems hard to script
>> > and awkward.
>>
>> Hi Stephen,
>>
>> Recently, I started working on implementing some self-tests for  
>> SRv6 on HMAC.
>> The command:
>>
>>   ip sr hmac set <keyid> <algo>
>>
>> uses getpass() internally, as you mentioned earlier, which can be  
>> inconvenient
>> for automation.
>>
>> To address this, Paolo Lungaroni has extended the command to support an
>> additional parameter called "secret" (this is within our internal fork of
>> iproute2):
>>
>>   ip sr hmac set 17 sha1 secret <your-secret>
>>
>> This enhancement allows the secret to be specified directly on the command
>> line, making it much more convenient for scripting and automated testing
>> environments.
>> If the "secret" parameter is not provided, the command will  
>> continue to behave
>> as before, prompting for the passphrase interactively (i.e., the legacy
>> behavior; we haven't modified the getpass() function, but we can consider to
>> update it).
>>
>> If you're interested, I can reach out to Paolo Lungaroni, the author of this
>> patchset, tomorrow morning (CEST) and ask him to prepare everything for
>> submission, including updates to the man page.
>
> Passwords and keys don't belong on the command line, since command lines
> are often visible to all users.  Standard input is the correct way to do
> it.  The issue you seem to referring to is that the command currently
> works only when standard input is a tty.  It should of course be fixed
> to work for any file, which would allow automation via something like
> 'ip sr hmac set 17 sha256 < passphrase.txt'.  (And to be clear, that's a
> separate issue from the lack of passphrase stretching.)
>
> When giving example commands, please also use sha256 instead of sha1.
>
> - Eric

Ciao Eric,

The scheme I followed to develop my patch proposal is inspired by the one
already present in ip xfrm and ip macsec.
These two features require the configuration of key entered inline in the
command prompt.
The keys are also shown in plain text in the show. It should be noted,  
however,
that there are mechanisms (in some cases optional, see more later) to mask the
printing of keys.

Here are a few examples:

MACsec:

# ip link add macsec0 link eth0 type macsec encrypt on
# ip macsec add macsec0 tx sa 0 pn 1 on key 00  
12345678901234567890123456789012
# ip macsec add macsec0 rx port 1 address 00:00:12:34:56:78
# ip macsec add macsec0 rx port 1 address 00:00:12:34:56:78 sa 0 pn 1  
on key 01 09876543210987654321098765432109
# ip macsec show
4: macsec0: protect on validate strict sc off sa off encrypt on  
send_sci on end_station off scb off replay off
     cipher suite: GCM-AES-128, using ICV length 16
     TXSC: 525400d4ad0f0001 on SA 0
         0: PN 1, state on, key 00000000000000000000000000000000
     RXSC: 325341bd7c270001, state on
         0: PN 1, state on, key 01000000000000000000000000000000
     offload: off

IPsec (xfrm)

# ip xfrm state add src fc00::1 dst fc00::2 \
           proto esp spi 0x00123456 reqid 0x12345678 mode transport \
           auth sha256  
0x1234567890123456789012345678901234567890123456789012345678901234 \
           enc aes  
0x0987654321098765432109876543210987654321098765432109876543210987
# ip xfrm state list
src fc00::1 dst fc00::2
   proto esp spi 0x00123456 reqid 305419896 mode transport
   replay-window 0
   auth-trunc hmac(sha256)  
0x1234567890123456789012345678901234567890123456789012345678901234 96
   enc cbc(aes)  
0x0987654321098765432109876543210987654321098765432109876543210987
   anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
   sel src ::/0 dst ::/0

In these cases, other methods of insertion via file, pipe or stdin are not
supported.

In ip sr hmac set, I simply took inspiration from the examples shown above and
replicated something similar while maintaining backward compatibility with the
previous interactive mode.

One more note: on ip xfrm state list, you can shadow the keys if you enter a
specific keyword (nokeys).

# ip xfrm state list nokeys
src fc00::1 dst fc00::2
   proto esp spi 0x00123456 reqid 305419896 mode transport
   replay-window 0
   auth-trunc hmac(sha256) <<Keys hidden>> 96
   enc cbc(aes) <<Keys hidden>>
   anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
   sel src ::/0 dst ::/0

I can update my patch to also support ip sr hmac show, which uses an identical
secret masking mechanism.

===

Regarding your statement: 'And to be clear, that's a separate issue from the
lack of passphrase stretching,' yes, you're right: they are indeed separate.

According to RFC8754, 'The pre-shared key identified by HMAC Key ID'  
is used as
is in the HMAC computation.

I'm trying to understand how 'stretching the passphrase' could work with other
network appliances that are not Linux. Stretching the passphrase only in the
Linux implementation seems to make it incompatible with RFC8754 and,
consequently, with other software and hardware that implement Segment Routing
over IPv6 HMAC.

As an example, at the computation level, I need to use the same key when
communicating with hardware routers and when calculating an HMAC that the
hardware device can verify. If we implement passphrase stretching in Linux,
what would be the input string I should provide in iproute2 to ensure that the
same key used in the hardware device (which does not perform passphrase
stretching) is used?

Could you please clarify what you intend to do and how to remain compatible
with RFC8754, which defines HMAC for SRv6?

Best regards,
Paolo.

Powered by blists - more mailing lists