| Internet-Draft | ADEM over TLS | August 2023 |
| Linker, et al. | Expires 2 March 2024 | [Page] |
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.¶
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.¶
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 (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.¶
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.¶
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.¶
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:¶
This document outlines the format of such extensions, how they are generated and verified for authenticity and the resulting security claims.¶
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.¶
ADEM-Aware Servers MUST only serve the ADEM-TLS extension as part of a NST message as defined in [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.¶
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.¶
ADEM-Naive clients which are compliant with TLS1.3 will ignore the ADEM extension in NSTs and discard NSTs with ticket lifetimes of 0.¶
This document has no IANA actions.¶
TODO acknowledge.¶