License Activation Protocol
draft-lorlacks-license-activation-protocol-01

Internet Engineering Task Force                              M. Lorlacks
Internet-Draft                                               Independent
Intended status: Experimental                             15 August 2021
Expires: 16 February 2022

                      License Activation Protocol
             draft-lorlacks-license-activation-protocol-01

Abstract

   This document defines an experimental method for uniform license
   activation mechanism for use in digital rights management (DRM).

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 16 February 2022.

Copyright Notice

   Copyright (c) 2021 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . . . .   3

Lorlacks                Expires 16 February 2022                [Page 1]
Internet-Draft         License Activation Protocol           August 2021

     3.1.  Provisioning  . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Service Discovery . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Request . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.4.  Response  . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   Document History [RFC Editor: Please remove this section] . . . .  10
   References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     Normative References  . . . . . . . . . . . . . . . . . . . . .  12
     Informative References  . . . . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   A common issue with on-premises software licensing is ensuring that
   licensing limitations are enforced.  Digital rights management (DRM)
   is an umbrella term for modeling legal licensing requirements in the
   form of executable code.  Part of DRM implementation is often
   communication with a server to ensure central knowledge of licenses
   in circulation.

   DRM implementations are in practice almost always one-off solutions
   for a particular product.  No observable efforts to standardize DRM
   have been made.  While DRM necessarily relies on either hardware or
   on security by obscurity, another use for DRM is to simplify license
   compliance for honest customers.  Consolidating the license
   information on a single server within an organization brings obvious
   benefits for keeping track of software inventory, obviating the need
   of manually triangulating licenses in use.

   It therefore seems beneficial to standardize a license management
   protocol that is both suitable for obfuscation without giving away
   too much information to active adversaries observing traffic and at
   the same time has reasonable implementation semantics for simplified
   cases where active adversaries are ignored, such as when it is too
   costly to spend great effort on software protection; modern
   obfuscation techniques are complex and accordingly expensive to
   implement, see e.g. [virtsc].  The license activation protocol
   presented herein aims to satisfy both of these needs.

2.  Conventions

   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
   [BCP14] when, and only when, they appear in all capitals, as shown
   here.

Lorlacks                Expires 16 February 2022                [Page 2]
Internet-Draft         License Activation Protocol           August 2021

   A "UUID" is a Universally Unique IDentifier in the sense of
   [RFC4122].  It is always respresented as a sequence of bytes.  The
   byte sequences use _big-endian_ encoding for all numerical components
   of the UUID.  For example, this means that the UUID
   "00112233-4455-6677-8899-aabbccddeeff" is encoded as the following
   sequence of bytes: 0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77,
   0x88, 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff.  This is mandated by
   [RFC4122]; _all other integer values in this document use little-
   endian encoding_.

3.  Protocol

   The protocol operates between a client and a server in a request-
   response fashion.  The client sends a request and the server sends a
   response.  Both request and response are each UDP datagrams[RFC0768].

   The protocol can both be used in a direct setup (customer client and
   vendor server communicate directly over the Internet) and an indirect
   setup (customer client and customer intermediate server communicate
   directly; customer intermediate server and vendor server communicate
   with each other using this same protocol).  Practical considerations
   may necessitate one or the other setup.  The choice between the
   setups must be made at provisioning time.

3.1.  Provisioning

   Prior to executing the protocol, every client must first be
   "provisioned".  Provisioning means equipping the client with:

   1.  a UUID that remains static for the installation time of the
       client (client ID),

   2.  unique, hard-to-predict information (client seed),

   3.  information about the expected server.

   The client ID MUST be generated at installation time.  It is
   RECOMMENDED that a version 4 UUID using a cryptographically secure
   random number generator is used.

   The client-side unique, hard-to-predict information (client seed) is
   typically supplied and generated at installation time.  It could, for
   example, consist of a unique license key concatenated with hardware
   information.  No format is specified; the actual value of the client
   seed is out of scope, but it MUST be a byte string consisting of one
   or more bytes; it is RECOMMENDED to include at least 16 bytes of
   cryptographically secure random data.

Lorlacks                Expires 16 February 2022                [Page 3]
Internet-Draft         License Activation Protocol           August 2021

   Additionally, the client must be aware of its own stock-keeping unit
   (SKU) identifier.  This is a UUID[RFC4122].

   The server information is typically hard-coded at compile time.  It
   consists of an X25519 public key[RFC7748] and an Ed25519 signing
   key[RFC8032].

3.2.  Service Discovery

   The license activation server has a DNS SRV record[RFC2782] for the
   service name "lap", e.g. _lap._udp.licensing.example.com.  The record
   describes the UDP port to use for the protocol.  No fixed UDP port is
   assigned; the UDP port for an individual deployment may therefore be
   chosen in accordance with IANA policy and the constraints of the
   network(s) involved.

   The license activation server MAY be auto-discovered using DNS-based
   service discovery (DNS-SD)[RFC6763].  The associated TXT record is
   empty.  Individual clients MUST provide a documented mechanism to
   manually override an auto-discovered server address.

3.3.  Request

   Once the client has discovered the license activation server to use
   (hostname, UDP port), it sends the request.  The request has this
   structure:

Lorlacks                Expires 16 February 2022                [Page 4]
Internet-Draft         License Activation Protocol           August 2021

   +==============+============+======================================+
   | Size (bytes) | Name       | Description                          |
   +==============+============+======================================+
   | 1            | Version    | Protocol version, currently always 0 |
   +--------------+------------+--------------------------------------+
   | 2            | Size       | Size of the request in bytes in      |
   |              |            | little-endian byte order             |
   +--------------+------------+--------------------------------------+
   | 5            | ClientTime | The client's idea of the current     |
   |              |            | time in Seconds Since the Epoch      |
   +--------------+------------+--------------------------------------+
   | 16           | RequestId  | Client-generated UUID uniquely       |
   |              |            | identifying this request             |
   +--------------+------------+--------------------------------------+
   | 16           | ClientId   | Client-generated UUID uniquely       |
   |              |            | identifying the client               |
   +--------------+------------+--------------------------------------+
   | 16           | SKUId      | Stock-keeping unit (SKU) UUID that   |
   |              |            | identifies the product of the client |
   +--------------+------------+--------------------------------------+
   | (variable)   | ClientSeed | The client seed value                |
   +--------------+------------+--------------------------------------+

                 Table 1: Client request packet structure

   There MUST NOT be any padding between the fields.

   If a client-generated UUID contains a timestamp by specification, the
   timestamp contained therein MUST NOT contradict the ClientTime
   fields.

   The Size field is computed starting at the Version field.  Since the
   client seed (and thus the ClientSeed field) is not permitted to be
   empty (see Section 3.1, Paragraph 4), the minimum value for the Size
   field is 73.

   The term "Seconds Since the Epoch" is defined in section 4.16 of the
   Base Definitions volume of [POSIX.1-2017]; the "Epoch" itself is
   defined in section 3.150 thereof.  "Seconds Since the Epoch" is
   commonly known as "UNIX time".  This field is 5 bytes in length to
   ensure this protocol working at least until the year 10,000.  This
   integer value is transmitted in little-endian byte order and does not
   include fractions of a second.

Lorlacks                Expires 16 February 2022                [Page 5]
Internet-Draft         License Activation Protocol           August 2021

   The client then generates an ephemeral X25519[RFC7748] key pair.
   Therefore, the client MUST have access to a cryptographically secure
   random number generator.  It performs X25519 with its ephemeral key
   and the server's public key that was obtained at provisioning time.
   The nonce and counter values are set to 0.  The key is the result of
   computing a BLAKE2b[RFC7693] hash as follows:

   1.  initialize a new BLAKE2b hash context with the following
       parameters: the key is set to the byte string corresponding to
       the ASCII encoding of the string "85d40cfd-
       f9f7-45e8-8f34-21851df92376-LAP-V0" and the output length is set
       to 32 bytes;

   2.  update it with the client's ephemeral X25519 public key;

   3.  update it with the server's X25519 public key;

   4.  update it with the server's Ed25519 public key;

   5.  update it with the X25519 shared secret;

   6.  output the hash.

   The encryption key is used with ChaCha20 and Poly1305
   (AEAD_CHACHA20_POLY1305)[RFC8439] to encrypt the request.  There is
   no additional authenticated data.  The client then transmits:

   1.  its 32-byte ephemeral X25519 public key;

   2.  the encrypted request;

   3.  the 16-byte Poly1305 authentication tag.

   The client MUST transmit this information in a single UDP packet, in
   that particular order and without padding inbetween to the server.
   This implies that a packet may not exceed the size of what can be
   transmitted in a single UDP packet.

3.4.  Response

   Before issuing a response, the server validates the client's request.
   If the result of the validation process is negative, the server does
   not respond to the request and drops the UDP packet.  Clients MUST
   NOT probe whether servers drop invalid requests.  In particular, the
   server validates that:

   1.   the result of the X25519 function is not all-zero;

Lorlacks                Expires 16 February 2022                [Page 6]
Internet-Draft         License Activation Protocol           August 2021

   2.   decryption succeeded (Poly1305 tag is valid);

   3.   the Version field is 0;

   4.   the Size field is equal to or greater than 73;

   5.   the UUIDs are, in fact, valid UUIDs according to [RFC4122];

   6.   if the client-generated UUIDs are version 1 UUIDs, their
        timestamp field matches the ClientTime fields;

   7.   the ClientTime fields match the server's idea of the current
        time with at most 30 seconds of difference;

   8.   the SKU ID is known to the server;

   9.   the ClientSeed field is valid according to the rules known to
        the server;

   10.  the client is licensed according to the rules known to the
        server.

   If the validation passes, the server sends the following response
   structure:

Lorlacks                Expires 16 February 2022                [Page 7]
Internet-Draft         License Activation Protocol           August 2021

      +============+============+==================================+
      | Size       | Name       | Description                      |
      | (bytes)    |            |                                  |
      +============+============+==================================+
      | 1          | Version    | Protocol version, currently      |
      |            |            | always 0                         |
      +------------+------------+----------------------------------+
      | 2          | Size       | Size of the response in bytes in |
      |            |            | little-endian byte order         |
      +------------+------------+----------------------------------+
      | 5          | ServerTime | The server's idea of the current |
      |            |            | time in Seconds Since the Epoch  |
      |            |            | in little-endian byte order, see |
      |            |            | Section 3.3, Paragraph 6         |
      +------------+------------+----------------------------------+
      | 16         | ClientId   | The client-generated UUID echoed |
      |            |            | back                             |
      +------------+------------+----------------------------------+
      | 16         | SKUId      | The SKU ID echoed back           |
      +------------+------------+----------------------------------+
      | 16         | LicenseId  | A UUID that identifies the       |
      |            |            | license; in case of volume       |
      |            |            | licensing, multiple clients MAY  |
      |            |            | share the same value             |
      +------------+------------+----------------------------------+
      | (variable) | ServerData | Application-specific data for    |
      |            |            | the client, which MAY be empty   |
      +------------+------------+----------------------------------+

                Table 2: Server response packet structure

   There MUST NOT be any padding between the fields.

   The Size field is computed starting at the Version field, i.e. the
   very beginning of the message.  Since the server data is permitted to
   be empty, the minimum value for the Size field is 56.

   The ServerData field may be used, for example, to transmit a date/
   time by which the client must consider itself de-activated and needs
   to re-authenticate or to transmit feature flags that are supposed to
   be enabled.

   The encryption key used by the client is then once more used to
   encrypt the response.  The first byte of the nonce is set to 1, i.e.
   the first 32-bit integer of the nonce is set to 1.  There is no
   additional authenticated data.  The server then transmits:

   1.  its 64-byte Ed25519 signature over the rest;

Lorlacks                Expires 16 February 2022                [Page 8]
Internet-Draft         License Activation Protocol           August 2021

   2.  the encrypted response;

   3.  the 16-byte Poly1305 authentication tag.

   The server MUST transmit this information in a single UDP packet, in
   that particular order and without padding inbetween to the client.
   This implies that a packet may not exceed the size of what can be
   transmitted in a single UDP packet.

   The client finally validates the server response according to the
   criteria it deems fit, but it MUST at least verify the Ed25519
   signature.  The client considers itself activated if the response
   validated successfully.

4.  Security Considerations

   The client SHOULD NOT be considered trusted.  Tampering with DRM is a
   notorious issue.  In particular, as noted in the previous sections,
   an implementation MUST verify all inputs rigorously.  Conversely, the
   client SHOULD NOT rely on the server's response being well-formed in
   principle; practical considerations (such as with embedded
   microprocessors) may necessitate this nonetheless.

   All routines and secrets pertaining to DRM SHOULD be protected by
   hardware-based mechanisms such as trusted platform modules (TPMs),
   hardware security modules (HSMs), and trusted execution environment
   technologies.  Obfuscation can also aid longevity of DRM by deterring
   insufficiently motivated attackers.

   The server information secrets SHOULD be protected by hardware
   security modules.  Cloud-based hardware security modules MAY be
   chosen for this task.  It is RECOMMENDED that accesses to these keys
   is monitored; for example, an automated system could cross-reference
   accesses to the secrets with timing of incoming requests.

   While the contents of activation responses in the ServerData field
   are unspecified, because activation procedures are often time-
   limited, the accuracy of the client's clock is important.  Otherwise,
   the server may issue responses that are too far into the future or
   already in the past for the client, bypassing temporal licensing
   limitations.  It is therefore RECOMMENDED that clients synchronize
   their time over the network, for example using NTP[RFC5905].

   In considering an implementation, care should be taken to avoid
   network amplification attacks.  Notably, the server response packet
   SHOULD NOT exceed the size of a client packet under any
   circumstances.

Lorlacks                Expires 16 February 2022                [Page 9]
Internet-Draft         License Activation Protocol           August 2021

   Using a fixed nonce for the encryption of the request and response is
   unproblematic because there is a new ChaPoly key for every request.
   Nonces only need to be unique per key.  Access to a cryptographically
   secure random number generator is required.  It is therefore no issue
   to fix the nonce since keys are guaranteed to be unique.

5.  IANA Considerations

   The discovery mechanism described in section Section 3.2 requires a
   service name.  The Service Name and Transport Protocol Port Number
   Registry therefore needs to be updated accordingly.  In accordance
   with [BCP165], it is hereby requested that IANA create a new entry in
   the Service Name and Transport Protocol Port Number Registry reading:

           +---------------------+----------------------------+
           | Service Name        | lap                        |
           +---------------------+----------------------------+
           | Transport Protocols | udp                        |
           +---------------------+----------------------------+
           | Assignee            | Maximilian Lorlacks        |
           |                     | <maxlorlax@protonmail.com> |
           +---------------------+----------------------------+
           | Contact             | Maximilian Lorlacks        |
           |                     | <maxlorlax@protonmail.com> |
           +---------------------+----------------------------+
           | Description         | License Activation         |
           |                     | Protocol                   |
           +---------------------+----------------------------+
           | Reference           | [this document]            |
           +---------------------+----------------------------+
           | Port Number         |                            |
           +---------------------+----------------------------+
           | Service Code        |                            |
           +---------------------+----------------------------+
           | Known Unauthorized  |                            |
           | Uses                |                            |
           +---------------------+----------------------------+
           | Assignment Notes    | Defined TXT keys: None.    |
           +---------------------+----------------------------+

                                 Table 3

Document History [RFC Editor: Please remove this section]

   Note to the RFC Editor: Please remove this section before
   publication.

   draft-lorlacks-license-activation-protocol-01

Lorlacks                Expires 16 February 2022               [Page 10]
Internet-Draft         License Activation Protocol           August 2021

   *  Because IETF ChaCha20 doesn't use numeric nonces like djb ChaCha20
      but rather a concatendation of three 32-bit little-endian integers
      for the nonce, the statement "The nonce is set to 1." in the
      Response section was unclear.  This was clarified to mean the
      first byte (= first 32-bit little-endian integer).

   *  Removed references to a ClientDate field in the request.  This was
      an artifact from early in development and entirely superseded by
      ClientTime.

   *  Made the Poly1305 tag come after the encrypted request; the
      previous version violated section 2.8 of RFC 8439 by putting the
      tag first.

   *  Actually use the X25519 shared secret in the key derivation
      function.

   *  Specified endianness of UUID byte representation; simultaneously
      removed copious amounts of xref tags to RFC 4122.

   *  Moved reference to RFC 5905 to the informative references as usage
      of NTP is only a suggestion, not a requirement.  (The provenance
      thereof as a normative suggestion dates back to a very early draft
      that used the NTP date and timestamp formats instead of five-byte
      UNIX time.)

   *  Added a section to the Security Consideration on why fixing the
      nonces is safe.

   *  Made access to a cryptographically secure random number generator
      a requirement.

   *  Gave <name>s to all content tables.

   *  Fixed a formatting issue where a BCP14 "MAY" wasn't marked up as
      such in the Service Discovery section.

   *  Fixed a formatting issue regarding a reference within the Request
      section.

   *  Grammar fix (lower-case continuation after semicolon in the
      Provisioning section)

   *  Grammar fix ("If a client-generated UUID contain a timestamp
      [...]" -> "contains")

References

Lorlacks                Expires 16 February 2022               [Page 11]
Internet-Draft         License Activation Protocol           August 2021

Normative References

   [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

              Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, May 2017.

              <https://www.rfc-editor.org/info/bcp14>

   [BCP165]   Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
              Cheshire, "Internet Assigned Numbers Authority (IANA)
              Procedures for the Management of the Service Name and
              Transport Protocol Port Number Registry", BCP 165,
              RFC 6335, August 2011.

              Touch, J., "Recommendations on Using Assigned Transport
              Port Numbers", BCP 165, RFC 7605, August 2015.

              <https://www.rfc-editor.org/info/bcp165>

   [POSIX.1-2017]
              IEEE, "Standard for Information Technology--Portable
              Operating System Interface (POSIX(R)) Base Specifications,
              Issue 7", IEEE 1003.1, 2017 Edition,
              DOI 10.1109/IEEESTD.2018.8277153, 31 January 2017,
              <https://ieeexplore.ieee.org/servlet/
              opac?punumber=8277151>.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              DOI 10.17487/RFC0768, August 1980,
              <https://www.rfc-editor.org/info/rfc768>.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              DOI 10.17487/RFC2782, February 2000,
              <https://www.rfc-editor.org/info/rfc2782>.

   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 4122,
              DOI 10.17487/RFC4122, July 2005,
              <https://www.rfc-editor.org/info/rfc4122>.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <https://www.rfc-editor.org/info/rfc6763>.

Lorlacks                Expires 16 February 2022               [Page 12]
Internet-Draft         License Activation Protocol           August 2021

   [RFC7693]  Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2
              Cryptographic Hash and Message Authentication Code (MAC)",
              RFC 7693, DOI 10.17487/RFC7693, November 2015,
              <https://www.rfc-editor.org/info/rfc7693>.

   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <https://www.rfc-editor.org/info/rfc7748>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.

   [RFC8439]  Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
              Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
              <https://www.rfc-editor.org/info/rfc8439>.

Informative References

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/info/rfc5905>.

   [virtsc]   Ahmadvand, M., Below, D., Banescu, S., and A. Pretschner,
              "VirtSC: Combining Virtualization Obfuscation with Self-
              Checksumming", SPRO '19, Proceedings of the 3rd ACM
              Workshop on Software Protection pp. 53-64,
              DOI 10.1145/3338503.3357723, November 2019,
              <https://doi.org/10.1145/3338503.3357723>.

Author's Address

   Maximilian Lorlacks
   Independent

   Email: maxlorlax@protonmail.com

Lorlacks                Expires 16 February 2022               [Page 13]