Tom H: WGLC comments on Section 11.9: Authentication

[Mike-Heard]

Section 11.9:

"Authentication (AUTH), RESERVED Only"

I suggest removing this section. There's little value in reserving the kind number without any specification of the protocol. Also, this is making a design decision that Auth is a SAFE which I disagree with, so if Auth is removed from the draft then we can defer the discussion as to whether Auth should be a SAFE or UNSAFE option.

[Mike-Heard]

Significant editorial effort will be required if this section is removed. If the WG consensus is to keep AUTH but to make it UNSAFE as argued in Issue #34, perhaps it can be merged with UENC (akin to the old AE) or placed in a companion section.

[gorryfair]

The potential merit of a placeholder to describe the role of AUTH, was explained by Joe previously - this should be factored into this issue.

[tompandadev]

If it's not removed then can the WG chairs do a consensus call? I believe the question is "Should Auth Option be UNSAFE such that it can be arbitrarily ignored by a receiver when the option is present?".

[Mike-Heard]

If it's not removed then can the WG chairs do a consensus call? I believe the question is "Should Auth Option be UNSAFE such that it can be arbitrarily ignored by a receiver when the option is present?".

I support Tom's request for a consensus call on this matter, but suggest that a more general question be asked: "Should AUTH and APC be left as-is, be redefined and UNSAFE options, or removed altogether?" See also Issue #34, where I made a similar suggestion.

[Mike-Heard]

The AUTH placeholder remains in -33 as a SAFE option. Text has been added to the UENC placeholder (Section 12.2) to state that it is expected to include all the functions of AUTH in addition to adding encryption:

The UNSAFE Encryption (UENC, Kind=193) option is reserved for all UDP encryption mechanisms. UENC is expected to provide all of the services of the AUTH option (Section 11.9) and in addition to encrypt the UDP user data and some (e.g., later, in sequence) UDP options, in a similar manner as TCP-AO-ENC [To18].

This provides a mechanism to allow the user to choose whether authentication failure causes packet discard or not.

[gorryfair]

On this topic, I see a difference between how the data in an option ought to be transported and how that option ought to be used by a library or application above UDP.

1. If a service is provided to support authentication, it ought to send AUTH option datagrams to carry the authentication data. This is the draft we are discussing in this issue.

2. The sender will also need to setup use of the option and to synchronise keying information. Once the AUTH service is setup, it will likely provide a service that passes only authenticated datagrams to the user of the service. That processing also manages any order/timeliness constraints, rekeying, etc.

I suggest the setup ought to be specified in a separate draft that provides the concept of operations for using AUTH.

[Mike-Heard]

Text has been added in -34 stating that the default of passing user data to the upper layer and not requiring that AUTH to be present is expected to be overridden when a security policy is configured; details are left to a future specification.

[tompandadev]

On Mon, Sep 16, 2024 at 12:14 PM Mike-Heard @.***> wrote:

Text has been added in -34 stating that the default of passing user data to the upper layer and not requiring that AUTH to be present is expected to be overridden when a security policy is configured; details are left to a future specification.

I don't see the point of this new text in a Standards Track RFC, it is not setting a normative requirement but just setting vague expectations of future behavior. Is it a SHOULD, MUST, or MAY that the default is overwritten? And leaving details to another specification, really meaning the normative requirements of the protocol, isn't particularly helpful in evaluating UDP options draft. What happens if when we do the normative requirements or implementation we find out that the default security posture isn't appropriate? IMO the best way to get the UDP options draft to move forward is to take the AUTH option out completely and define it in its own specification.

— Reply to this email directly, view it on GitHub https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/58#issuecomment-2353715949, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASQYCK4JL26YHYMWXFVE3STZW4UXVAVCNFSM6AAAAABG5LVDB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJTG4YTKOJUHE . You are receiving this because you commented.Message ID: @.***>

[gorryfair]

I'm closing this issue: I think it is clear that the default will be overwritten if a policy is used to manage the protocol procedures. The I-D does describe how parsing different options relates to one another. I will check the same is noted for other options where the default is overridden by the upper layer/application processing.

[tompandadev]

On Fri, Sep 27, 2024, 12:54 AM Gorry Fairhurst @.***> wrote:

I'm closing this issue: I think it is clear that the default will be overwritten if a policy is used to manage the protocol procedures. The I-D does describe how parsing different options relates to one another. I will check the same is noted for other options where the default is overridden by the upper layer/application processing.

Gorry,

That doesn't answer my objection which seems to also be what Sebastian was objecting to in the last discussion about AUTH. Ignoring AUTH is not safe.

Tom

—

Reply to this email directly, view it on GitHub https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/58#issuecomment-2378643255, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASQYCK5LJ6ZCHJCFWEN25OLZYUFLBAVCNFSM6AAAAABG5LVDB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZYGY2DGMRVGU . You are receiving this because you commented.Message ID: @.***>