Increasing maximum password length on auth_pass

[toloveru]

Is your feature request to resolve a problem or provide enhanced functionality? Please describe.
I have successfully deployed keepalived on a set of two gateway devices (one LXC container and one Raspberry Pi, both running Debian 10), and perform as expected. However, when selecting the password to make the two of them authenticate to each other, the password was getting truncated. The length of this initial password was 64 alphanumeric characters, generated by a password manager. After doing some research on the subject, I arrived at this Cisco documentation for a device called VPN 3000 Concentrator. Apparently that's one of the devices that specifies 8 characters as a maximum password length. However, for a cluster that only consists of Linux devices running keepalived, this seems to be an unnecessary limitation.

Describe the solution you would like
Given the truncation feature already existing in the code, the detection and handler functions appear to be already laid out. This leads me to believe that behavior for a keepalived-only cluster where the password can be of arbitrary length, would be fairly trivial to implement. With this, security can be substantially improved. This would be in comparison to the current status quo, where the amount of tries required to crack an 8-character alphanumeric password would be (26+26+10)^8, which is not that high a number if you can crack at many thousands or even millions of attempts every second (divide the previous with this attempts/s rate, and divide further to get minutes, hours, days, etc).

Describe alternatives you have considered
The config file specifies both auth_type and auth_pass variables. Given this, I suspect that other mechanisms such as keys may also be available. This may be a viable alternative, if these key files can be longer and/or have larger character sets.

Would the feature request be of benefit only to you, or is it more generally applicable?
This feature looks like it could benefit all keepalived users, if their cluster of consideration does not include any other hardware that uses its own VRRP implementation (Cisco, Juniper etc).

Keepalived version
Keepalived v2.0.10 (11/12,2018)
Built with kernel headers for Linux 4.18.20
Running on Linux 5.11.11 #1 SMP Sat Apr 3 03:00:21 CEST 2021

This output is truncated, a full output is available on my website.

Additional context
RFC 5798 section 9 talks about security considerations that have been made for VRRPv3. From here, I conclude that security has been a weak point of VRRP for quite some time. It does not however say anything about this password limitation. It does mention that security considerations in previous versions of VRRP were inadequate. It also says that authentication has not at all been considered this time. Would it be appropriate to conclude that authentication mechanisms are left to the implementations themselves to consider? If so, that means that changes in authentication mechanisms like the one suggested here, would not violate the RFC's. I only had a cursory look though, so I may be mistaken on this.
If anything is missing in this post, feel free to ask further questions below. Afterwards, I will update the post accordingly.

[pqarmitage]

RFC 3768 section 5.3.6, which is the last RFC for VRRPv2 stated:

Note:  Earlier version of the VRRP specification had several defined
   authentication types [RFC2338](https://www.rfc-editor.org/rfc/rfc2338).  These were removed in this
   specification because operational experience showed that they did not
   provide any real security and would only cause multiple masters to be
   created.

So VRRPv2 had authentication removed in 2004, and VRRPv3 has never supported authentication, and therefore using authentication does not comply with any current VRRP RFC.

RFC 2338 section 5.3.6 describes the authentication that originally existed in VRRPv2 before it was removed, and it states that it allowed for additional authentication types to be defined, although I am not aware of any that were.

If you look at the authentication data field in the RFC 2338 VRRP header, you will see that it is 8 octets long, and therefore it is not possible to increase the plain text password length. If you want some form of stronger authentication then I suggest you use the AH type authentication.

You refer to being able to crack a password with (26 + 26 + 10)^8 options (which is greater than 2^47), but how would you know you have got the correct password? You don't get any response for sending a correct or incorrect password. You would need to be able to see that the current master had stopped sending VRRP adverts in order to suggest that you had found the correct password. For that, you would have to wait at least 1 second (depending on the advert interval), but you would need to be able to monitor traffic on the network in order to know that a VRRP master has stopped sending adverts. I suppose you could send 1 million adverts at a time, with different passwords in each advert, and then wait to see if the master had stopped sending adverts, and then once you have found a block of 1 million, halve the number of adverts you send each time until you have found the correct password. With the 1 second plus delay in sending blocks of adverts, if 1 million were sent at a time it would take over 6 years to try every password with the number of passwords you have specified. However, the password can contain any printable character, so removing space and double quote (since keepalived limits configurating those) and you have 93^8 passwords (greater that 2^52), and so time taken to try all passwords (if 1 million are sent per second) would be in excess of 169 years. On the other hand, given that you would need access to the network, you could just simply extract the plain text password from an advert with tcpdump or wireshark.