[tsvwg] Re: Request for consensus call for Auth in UDP options

[Christian Huitema <[e-mail]>]

My personal feeling is that authentication only is not terribly useful. 
We can see that in IPv6, where the AH header is used much less than the 
ESP header. If the endpoints have negotiated a key, they should use 
something like AEAD encryption, not just authentication. That would 
probably help address some of the concerns about peers ignoring the 
authentication: they may access the content of a field that is protected 
by authentication only, but they not be able to do that if the field is 
encrypted -- and AEAD gives you authentication more or less "for free".

In any case, shipping any protocol today that does not have a strong 
security posture seems like a very bad idea.

-- Christian Huitema

On 9/6/2024 7:40 PM, [e-mail] wrote:
> Tom,
>
> Sending AUTH to an endpoint that doesn’t expect it and have a key is useless as well.
>
> That endpoint can and should already override.
>
> A fundamental design principle - that was agreed by rough consensus - is that the receiver decides what to do with options, not the sender.
>
> Until a NEW point has been made, I will wait to see what others think.
>
> Joe
>
> —
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com
>
>> On Sep 6, 2024, at 7:34 PM, Tom Herbert <tom=[e-mail]> wrote:
>>
>> On Fri, Sep 6, 2024 at 7:06 PM [e-mail]
>> <[e-mail]> wrote:
>>> Hi Tom (et al.),
>>>
>>> As context:
>>>
>>> - NOBODY said a receiver cannot override the default behavior and decide to drop anything arriving with AUTH on a given socket.
>>> That’s already part of the design and a required capability.
>>>
>>> - what the current doc IS currently saying is that, *absent such explicit action by a receiver*, that AUTH doesn’t itself cause a packet to be dropped before being given to the receiver endpoint. Note that a failed AUTH would arrive with “AUTH failed” as context, not simply received without any indication of whether AUTH was present or whether it failed.
>>>
>>> The goal of the current *default* behavior is to act like a legacy endpoint, i.e., to allow users to enable AUTH on transmission without immediately breaking legacy endpoints, which would silently drop the AUTH anyway. Endpoints that know better - an endpoint that has installed a key for that socket - would already presumably override that default for that socket. The goal is to ensure that AUTH doesn’t break things unless the receiver takes specific action to NOT act like a legacy endpoint.
>> Joe,
>>
>> I fundamentally disagree that supporting legacy receivers is more
>> important than security. But in the case of the Auth option it's a
>> moot point, there is no valid use case of ever sending the
>> authentication option to a legacy receiver.
>>
>> Authentication requires some sort of key negotiation, which means for
>> someone to be able to send the option they were told what key to use
>> by the receiving site. So for a site to go at all the expense of
>> giving out keys, but then to not bother actually validating them at
>> receivers makes no sense. If receivers are allowed to ignore
>> authentication then that opens the door for a misconfiguration, and if
>> they willfully ignore authentication after negotiating keys that might
>> even be legal problem in some jurisdictions (i.e. this is akin to a
>> landlord giving a tenant keys to an apartment without bothering to
>> tell them that *any* key will work to get into their apartment; when
>> someone breaks and steals all the tenant's stuff the landlord is going
>> to be held liable).
>>
>>> That is the current state of the document and was our understanding of “rough consensus”. If that’s not the case, the chair can help us either find such consensus or direct otherwise.
>> There has never been any consensus on this, that's why I am asking for
>> a consensus call.
>>
>> Tom
>>
>>> Joe
>>>
>>> —
>>> Dr. Joe Touch, temporal epistemologist
>>> www.strayalpha.com
>>>
>>> On Sep 6, 2024, at 6:33 PM, Tom Herbert <tom=[e-mail]> wrote:
>>>
>>> TSVWG chairs,
>>>
>>> I have raised an objection to the UDP Options draft that the
>>> Authentication may be ignored by a receiver. I believe this is a
>>> serious security vulnerability in the protocol.
>>>
>>> If a sender uses the option that must mean that a key negotiation must
>>> have happened, so when the sender places the option in a packet they
>>> naturally have the full expectation that the receiver will validate
>>> the authentication credentials. If the receiver elects to ignore the
>>> authentication then they will not only allow legitimate senders but an
>>> attacker will be able to access the system as well-- so basically
>>> there is no security and the user is at risk for harm. Ignoring an
>>> authentication option is not safe.
>>>
>>> The counter argument seems to be that it should be up to the receiver
>>> to decide if the authentication option must be validated. That stands
>>> in contrast to other authentication protocols like IPv6 AH that
>>> explicitly require authentication option to be validated if it is
>>> present (if they can't validate, then the packet MUST be dropped). If
>>> the idea is that the user decides this then security is wholly
>>> dependent on the user configuring the protocol correctly, so a slight
>>> misconfiguration could allow a major breach (note this cannot happen
>>> in IPv6 AH).
>>>
>>> Please consider doing a consensus call on whether ignoring an
>>> Authentication option in UDP options is allowed.
>>>
>>> Thanks,
>>> Tom
>>>
>>>
>