ADEM Working Group F. E. Linker Internet-Draft ETH Zürich Intended status: Standards Track D. Jackson Expires: 2 March 2024 None D. Basin ETH Zürich 30 August 2023 Serving an Authenticated Digital EMblem over TLS draft-adem-wg-adem-tls-latest Abstract This document describes a mechanism in Transport Layer Security (TLS) to distribute _Authenticated Digital EMblem_ (ADEM) tokens [ADEM-CORE]. ADEM tokens encode that an asset is protected under international humanitarian law. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-adem-wg-adem-tls/. Source for this draft and an issue tracker can be found at https://github.com/adem-wg/adem-spec. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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 2 March 2024. Copyright Notice Copyright (c) 2023 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 (https://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 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. Conventions and Definitions 3. Overview 4. The Extension 5. Behaviour 5.1. ADEM-Aware Servers 5.2. ADEM-Aware Clients 5.3. ADEM-Naive Clients 6. Security Considerations 7. IANA Considerations 8. Normative References Acknowledgments Authors' Addresses 1. Introduction The ADEM Core document [ADEM-CORE] specifies how a set of _tokens_, encoded as JSON Web Signatures (JWSs) [RFC7515], can constitute _signs of protection_. Such signs of protection indicate that a digital asset is protected under international humanitarian law (IHL). This document describes a UDP-based distribution method for ADEM tokens, termed ADEM-UDP. This document presents an extension to TLS which allows for TLS servers to distribute ADEM tokens in a backwards compatible fashion. DISCLAIMER: This draft is work-in-progress and has not yet seen any security analysis. It should not be used as a basis for building production systems. 2. Conventions and Definitions 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. Data formats and TLS notation come from [RFC8446], Section 3 (https://datatracker.ietf.org/doc/html/rfc8446#section-3). 3. Overview This document describes a TLS-based distribution method for ADEM tokens, termed ADEM-TLS. The format and meaning of ADEM tokens is described in [ADEM-CORE]. ADEM-TLS consists of an additional TLS extension, which can be included by the server in the NewSessionTicket (NST) message. This TLS extension contains the ADEM token and all associated metadata. NST messages are typically used to deliver preshared keys for use in future TLS sessions and are attractive for ADEM-TLS for several reasons: * They are server-initiated and do not require clients to prompt for them. * Unlike all other TLS messages, servers may send unknown extensions which clients must tolerate. * Servers can send multiple NST messages, allowing for both regular and ADEM-TLS specific use. This document outlines the format of such extensions, how they are generated and verified for authenticity and the resulting security claims. 4. The Extension Emblems in ADEM are encoded as JSON Web Signatures (JWS) [RFC7515] by standard. [ADEM-CORE] additionally specifies the option to encode tokens as CBOR Web Token (CWT) [RFC8392]. To transmit tokens over TLS, they MUST be encoded as CWT. The atomic unit of transmission in scope of this standard are tokens, i.e., emblems or endorsements encoded as CWT. opaque Token<1..2^16-1>; 2^16-1 marks the maximum size of extension data in TLS. Neither [ADEM-CORE] nor CWT mention a maximum size for emblems, endorsements, or the encoding thereof. In practice, though, we expect a Token to occupy between 2^10-2^12 bytes. The ADEM-TLS extension data is encoded as the following structure: struct { Token tokens<1..2^16-4>; } ADEM; tokens: This field bears all tokens to be transmitted. 5. Behaviour 5.1. ADEM-Aware Servers ADEM-Aware Servers MUST only serve the ADEM-TLS extension as part of a NST message as defined in [RFC8446], Section 4.6 (https://datatracker.ietf.org/doc/html/rfc8446#section-4.6). The NST ticket_lifetime lifetime MUST be set to 0. If the ADEM-Aware Server intends to send the ADEM Extension, it SHOULD include it in the first NST message and the first NST message should be sent prior to any Application Data from the server. Subsequent NST messages maybe interleaved with the Application Data. If the emblems and endorsements do not fit within a single extension, the Server SHOULD send additional NST messages containing the extension. The Server SHOULD send an NST message without the ADEM extension to indicate that no further extensions will follow. This ticket_lifetime may or may-not be set to 0 depending on whether the TLS Server wishes to offer Resumption. 5.2. ADEM-Aware Clients ADEM-Aware Clients SHOULD expose the ADEM state of the connection to the application layer. ADEM States are: enum { unknown(1), unaware(2), pending(3), known(4) } A connection starts in the unknown state. If the first NST or Application Data message is received without the ADEM extension, it moves to the unaware state. Otherwise, if the first NST contains the ADEM extension it moves to the pending state. Once a NST is received without the ADEM extension it moves to the known state. ADEM-Aware clients should expose the list of received tokens to the application for further processing. 5.3. ADEM-Naive Clients ADEM-Naive clients which are compliant with TLS1.3 will ignore the ADEM extension in NSTs and discard NSTs with ticket lifetimes of 0. 6. Security Considerations 7. IANA Considerations This document has no IANA actions. 8. Normative References [ADEM-CORE] Linker, F. E., Jackson, D., and D. Basin, "An Authenticated Digital EMblem - Core Specification", n.d., <./draft-adem-wg-adem-core.html>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Acknowledgments TODO acknowledge. Authors' Addresses Felix E. Linker ETH Zürich Email: flinker@inf.ethz.ch Dennis Jackson None Email: ietf@dennis-jackson.uk David Basin ETH Zürich Email: basin@inf.ethz.ch