Re: [radext] Extended IDs

[Stefan Winter <[e-mail]>]

Hello,

again as a chair:

regarding the question of whether overloading of Request-Authenticator
should be considered harmful, I think the message from Peter below best
summarises the deployed reality in RADIUS.

Basically, it makes clear that the decision to overload
Message-Authenticator or not is not on our table. That decision has been
taken ages ago, by this working group, and for a good number of RADIUS
attributes.

So, for the discussion at hand, fears about overloading the
Request-Authenticator can safely be considered a non-argument.

Greetings,

Stefan Winter

> On Fri, 1 Dec 2017, Jakob Heitz (jheitz) wrote:
>
>> What if the quantum computers turn out to live up to their promises?
>> Then we can throw out all this authentication stuff and decide to not
>> share our Ethernets with the attackers instead. No more request
>> authenticator.
>
> RADIUS security already lost cause no matter what :(
>
> Best practice for many years - use a secure transport and or RADIUS
> over (D)TLS.  Regardless of selected security option in all cases
> operation of authenticator is maintained.
>
>> The request authenticator is already overloaded. It may be used for
>> the CHAP challenge. Now, you want another overload?
>
> Authenticator currently also used for at least following:
>
> Tunnel Passwords
> Message-Authenticator
> PAP
> CHAP
> MPPE Keys
>
> Clearly no possibility of authenticator ever changing in RADIUS
> protocol without creation of an incompatible replacement.  In event of
> an incompatible replacement there would be no need for either of these
> two drafts.
>
> I am aware of no practical downside to "Overloading".
>
> regards,
> Peter
>