Internet DRAFT - draft-touch-tsvwg-udp-auth-opt
draft-touch-tsvwg-udp-auth-opt
TSVWG J. Touch
Internet Draft Independent Consultant
Intended status: Experimental March 3, 2024
Intended updates: TBD
Expires: September 2024
The UDP Authentication Option
draft-touch-tsvwg-udp-auth-opt-00.txt
Abstract
This document extends UDP by defining a framework for an
authentication option.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
https://www.ietf.org/shadow.html
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 3, 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
Touch Expires September 3, 2024 [Page 1]
Internet-Draft The UDP Authentication Option March 2024
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
1. Introduction ..................................................2
2. Conventions used in this document .............................2
3. Terminology ...................................................2
4. Background ....................................................3
5. Authentication (AUTH) .........................................3
6. Security Considerations .......................................4
7. IANA Considerations ...........................................5
8. References ....................................................5
8.1. Normative References .....................................5
8.2. Informative References ...................................5
9. Acknowledgments ...............................................6
Appendix A. Implementation Information ...........................8
1. Introduction
TBD
This document currently contains a copy of the text from draft-ietf-
tsvwg-udp-options, to be updated.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
In this document, the characters ">>" preceding an indented line(s)
indicates a statement using the key words listed above. This
convention aids reviewers in quickly identifying or finding the
portions of this RFC covered by these key words.
3. Terminology
The following terminology is used in this document:
o TBD
Touch Expires September 3, 2024 [Page 2]
Internet-Draft The UDP Authentication Option March 2024
4. Background
TBD
5. Authentication (AUTH)
The Authentication (AUTH, Kind=9) option is intended to allow UDP to
provide a similar type of authentication as the TCP Authentication
Option (TCP-AO) [RFC5925]. AUTH covers the UDP user data. AUTH
supports NAT traversal in a similar manner as TCP-AO [RFC6978].
Figure 1 shows the UDP AUTH format, whose contents are identical to
that of the TCP-AO option, with the addition of a 32-bit unsigned
sequence number. The sequence number is used to differentiate
otherwise identical datagrams for cryptographic purposes; it is
intended to not repeat during the lifetime of a security
association, but are otherwise meaningless (e.g., they can be
monotonically increased except during rollover). Because AUTH
sequence numbers are not coordinated and not reliably transmitted,
in contrast to TCP, they cannot be used to derive session traffic
keys. During an association, the one-byte KeyID and ReceiveNextKeyID
(RNKID) fields serve the same purpose as for TCP-AO, allowing the
active keys used in either direction to change in a coordinated
manner.
+--------+--------+--------+--------+
| Kind=9 | Len | KeyID | RNKID |
+--------+--------+--------+--------+
| Sequence Number |
+--------+--------+--------+--------+
| MAC... |
+--------+--------+--------+--------+
...
+--------+--------+--------+--------+
| ...MAC |
+--------+--------+--------+--------+
Figure 1 UDP AUTH option format
Like TCP-AO, AUTH is not negotiated in-band. Its use assumes both
endpoints have populated Master Key Tuples (MKTs), used to exclude
non-protected traffic.
TCP-AO generates unique traffic keys from a hash of TCP connection
parameters. UDP lacks a three-way handshake to coordinate
connection-specific values, such as TCP's Initial Sequence Numbers
(ISNs) [RFC9293], thus AUTH's Key Derivation Function (KDF) uses
Touch Expires September 3, 2024 [Page 3]
Internet-Draft The UDP Authentication Option March 2024
zeroes as the value for both ISNs. This means that the AUTH reuses
keys when socket pairs are reused, unlike TCP-AO.
>> UDP packets with incorrect AUTH HMACs MUST be passed to the
application by default, e.g., with a flag indicating AUTH failure.
>> UDP fragments with individual incorrect AUTH HMACs MUST be
accumulated and passed to the application by default as part of the
reassembled packet.
>> If used with UDP fragments, AUTH MUST be configured to cover the
UDP option area (because fragments have an empty UDP data area).
Like all non-UNSAFE UDP options, AUTH needs to be silently ignored
when failing. This silently-ignored behavior ensures that option-
aware receivers operate the same as legacy receivers unless
overridden.
In addition to the UDP user data (which is always included), AUTH
can be configured to either include or exclude the surplus area
(again, the latter is not allowed for UDP fragments), in a similar
way as can TCP-AO can optionally exclude TCP options. When UDP
options are covered, the OCS value and AUTH (and later, UENC) hash
areas are zeroed before computing the AUTH hash. It is important to
consider that options not yet defined might yield unpredictable
results if not confirmed as supported, e.g., if they were to contain
other hashes or checksums that depend on the surplus area contents.
This is why such dependencies are not permitted except as defined
for the OCS and the AUTH (and later, UENC) option.
Similar to TCP-AO-NAT, AUTH (and later, UENC) can be configured to
support NAT traversal, excluding (by zeroing out) one or both of the
UDP ports and corresponding IP addresses [RFC6978].
6. Security Considerations
TBD
UDP options are not covered by DTLS (datagram transport-layer
security). Despite the name, neither TLS [RFC8446] (transport layer
security, for TCP) nor DTLS [RFC9147] (TLS for UDP) protect the
transport layer. Both operate as a shim layer solely on the user
data of transport packets, protecting only their contents. Just as
TLS does not protect the TCP header or its options, DTLS does not
protect the UDP header or the new options introduced by this
document. Transport security is provided in TCP by the TCP
Authentication Option (TCP-AO [RFC5925]) or in UDP by the
Touch Expires September 3, 2024 [Page 4]
Internet-Draft The UDP Authentication Option March 2024
Authentication (AUTH) option (Section 5) and UNSAFE Encryption
(UENC) option (Section Error! Reference source not found.). T
ransport headers are also protected as payload when using IP
security (IPsec) [RFC4301].
7. IANA Considerations
TBD
8. References
8.1. Normative References
[Fa23] Fairhurst, G., T. Jones, "Datagram PLPMTUD for UDP
Options," draft-ietf-tsvwg-udp-options-dplpmtud, Jun.
2023.
[RFC768] Postel, J., "User Datagram Protocol," RFC 768, August
1980.
[RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts --
Communication Layers," RFC 1122, Oct. 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997.
[RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication
Option," RFC 5925, June 2010.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words," RFC 2119, May 2017.
8.2. Informative References
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, Dec. 2005.
[RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field,"
RFC 6864, Feb. 2013.
[RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT
Traversal", RFC 6978, July 2013.
Touch Expires September 3, 2024 [Page 5]
Internet-Draft The UDP Authentication Option March 2024
[RFC8126] Cotton, M., B. Leiba, T. Narten, "Guidelines for Writing
an IANA Considerations Section in RFCs," RFC 8126, June
2017.
[RFC8200] Deering, S., R. Hinden, "Internet Protocol Version 6
(IPv6) Specification," RFC 8200, Jul. 2017.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3," RFC 8446, Aug. 2018.
[RFC8504] Chown, T., J. Loughney, T. Winters, "IPv6 Node
Requirements," RFC 8504, Jan. 2019.
[RFC9147] Rescorla, E., H. Tschofenig, N. Modadugu, "Datagram
Transport Layer Security Version 1.3," RFC 9147, Apr.
2022.
[RFC9187] Touch, J., "Sequence Number Extension for Windowed
Protocols," RFC 9187, Jan. 2022.
[RFC9293] Eddy, W. (Ed.), "Transmission Control Protocol," STD 7,
RFC 9293, Aug. 2022.
[CERT18] CERT Coordination Center, "TCP implementations vulnerable
to Denial of Service,", Vulnerability Note VU 962459,
Software Engineering Institute, CMU, 2018,
https://www.kb.cert.org/vuls/id/962459.
[To18] Touch, J., "A TCP Authentication Option Extension for
Payload Encryption," draft-touch-tcp-ao-encrypt, Jul.
2018.
9. Acknowledgments
This work benefitted from discussions on the IETF TSVWG and SPUD
email lists.
This document was prepared using 2-Word-v2.0.template.dot.
Touch Expires September 3, 2024 [Page 6]
Internet-Draft The UDP Authentication Option March 2024
Authors' Addresses
Joe Touch
Manhattan Beach, CA 90266 USA
Phone: +1 (310) 560-0334
Email: touch@strayalpha.com
Touch Expires September 3, 2024 [Page 7]
Internet-Draft The UDP Authentication Option March 2024
Appendix A.Implementation Information
The following information is provided to encourage interoperable API
implementations.
System-level variables (sysctl):
Name default meaning
----------------------------------------------------
net.ipv4.udp_opt 0 UDP options available
net.ipv4.udp_opt_ocs 1 Default use OCS
net.ipv4.udp_opt_apc 0 Default include APC
net.ipv4.udp_opt_frag 0 Default fragment
net.ipv4.udp_opt_mds 0 Default include MDS
net.ipv4.udp_opt_mrds 0 Default include MRDS
net.ipv4.udp_opt_req 0 Default include REQ
net.ipv4.udp_opt_resp 0 Default include RES
net.ipv4.udp_opt_time 0 Default include TIME
net.ipv4.udp_opt_auth 0 Default include AUTH
net.ipv4.udp_opt_exp 0 Default include EXP
net.ipv4.udp_opt_uenc 0 Default include UENC
net.ipv4.udp_opt_uexp 0 Default include UEXP
Socket options (sockopt), cached for outgoing datagrams:
Name meaning
----------------------------------------------------
UDP_OPT Enable UDP options (at all)
UDP_OPT_OCS Use UDP OCS
UDP_OPT_APC Enable UDP APC option
UDP_OPT_FRAG Enable UDP fragmentation
UDP OPT MDS Enable UDP MDS option
UDP OPT MRDS Enable UDP MRDS option
UDP OPT REQ Enable UDP REQ option
UDP OPT RES Enable UDP RES option
UDP_OPT_TIME Enable UDP TIME option
UDP OPT AUTH Enable UDP AUTH option
UDP OPT EXP Enable UDP EXP option
UDP_OPT_UENC Enable UDP UENC option
UDP OPT UEXP Enable UDP UEXP option
Send/sendto parameters:
Connection parameters (per-socketpair cached state, part UCB):
Touch Expires September 3, 2024 [Page 8]
Internet-Draft The UDP Authentication Option March 2024
Name Initial value
----------------------------------------------------
opts_enabled net.ipv4.udp_opt
ocs_enabled net.ipv4.udp_opt_ocs
>> The JUNK option is included for debugging purposes, and MUST NOT
be enabled otherwise.
System variables
net.ipv4.udp_opt_junk 0
Touch Expires September 3, 2024 [Page 9]
Internet-Draft The UDP Authentication Option March 2024
System-level variables (sysctl):
Name default meaning
----------------------------------------------------
net.ipv4.udp_opt_junk 0 Default use of junk
Socket options (sockopt):
Name params meaning
------------------------------------------------------
UDP_JUNK - Enable UDP junk option
UDP_JUNK_VAL fillval Value to use as junk fill
UDP_JUNK_LEN length Length of junk payload in bytes
Connection parameters (per-socketpair cached state, part UCB):
Name Initial value
----------------------------------------------------
junk_enabled net.ipv4.udp_opt_junk
junk_value 0xABCD
junk_len 4
Touch Expires September 3, 2024 [Page 10]