A Password Authenticated Key Exchange Extension for TLS 1.3
draft-bmw-tls-pake13-00

Network Working Group                                          L. Bauman
Internet-Draft                                                  S. Menon
Intended status: Informational                                C. A. Wood
Expires: 24 April 2025                                       Apple, Inc.
                                                         21 October 2024

      A Password Authenticated Key Exchange Extension for TLS 1.3
                        draft-bmw-tls-pake13-00

Abstract

   The pre-shared key mechanism available in TLS 1.3 is not suitable for
   usage with low-entropy keys, such as passwords entered by users.
   This document describes an extension that enables the use of
   password-authenticated key exchange protocols with TLS 1.3.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Transport Layer
   Security Working Group mailing list (tls@ietf.org), which is archived
   at https://mailarchive.ietf.org/arch/browse/tls/.

   Source for this draft and an issue tracker can be found at
   https://github.com/chris-wood/draft-bmw-tls-pake13.

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 24 April 2025.

Bauman, et al.            Expires 24 April 2025                 [Page 1]
Internet-Draft                TLS 1.3 PAKE                  October 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 (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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  PAKE Integration in TLS . . . . . . . . . . . . . . . . . . .   4
     4.1.  Client Behavior . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Server Behavior . . . . . . . . . . . . . . . . . . . . .   5
     4.3.  Key Schedule Modifications  . . . . . . . . . . . . . . .   6
     4.4.  Server Simulation . . . . . . . . . . . . . . . . . . . .   7
   5.  Compatible PAKE Protocols . . . . . . . . . . . . . . . . . .   7
   6.  SPAKE2+ Integration . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Protocol Setup  . . . . . . . . . . . . . . . . . . . . .   8
     6.2.  Protocol Execution  . . . . . . . . . . . . . . . . . . .   8
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     8.1.  SPAKE2+ Security Considerations . . . . . . . . . . . . .  11
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  Named PAKE registry . . . . . . . . . . . . . . . . . . .  11
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     10.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   DISCLAIMER: Most of this text is copied from draft-barnes-tls-pake-04
   and is in the process of being updated.

   DISCLAIMER: This is a work-in-progress draft and has not yet seen
   significant security analysis.  It should not be used as a basis for
   building production systems.

Bauman, et al.            Expires 24 April 2025                 [Page 2]
Internet-Draft                TLS 1.3 PAKE                  October 2024

   In some applications, it is desirable to enable a client and server
   to authenticate to one another using a low-entropy pre-shared value,
   such as a user-entered password.

   In prior versions of TLS, this functionality has been provided by the
   integration of the Secure Remote Password PAKE protocol (SRP)
   [RFC5054].  The specific SRP integration described in RFC 5054 does
   not immediately extend to TLS 1.3 because it relies on the Client Key
   Exchange and Server Key Exchange messages, which no longer exist in
   1.3.

   TLS 1.3 itself provides a mechanism for authentication with pre-
   shared keys (PSKs).  However, PSKs used with this protocol need to be
   "full-entropy", because the binder values used for authentication can
   be used to mount a dictionary attack on the PSK.  So while the TLS
   1.3 PSK mechanism is suitable for the session resumption cases for
   which it is specified, it cannot be used when the client and server
   share only a low-entropy secret.

   Enabling TLS to address this use case effectively requires the TLS
   handshake to execute a password-authenticated key establishment
   (PAKE) protocol.  This document describes a TLS extension pake that
   can carry data necessary to execute a PAKE.

   This extension is generic, in that it can be used to carry key
   exchange information for multiple different PAKEs.  We assume that
   prior to the TLS handshake the client and server will both have
   knowledge of the password or PAKE-specific values derived from the
   password (e.g. augmented PAKEs only require one party to know the
   actual password).  The choice of PAKE and any required parameters
   will be explicitly specified using IANA assigned values.  As a first
   case, this document defines a concrete protocol for executing the
   SPAKE2+ PAKE protocol [RFC9383].

2.  Terminology

   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.

   The mechanisms described in this document also apply to DTLS 1.3
   [RFC9147], but for brevity, we will refer only to TLS throughout.

Bauman, et al.            Expires 24 April 2025                 [Page 3]
Internet-Draft                TLS 1.3 PAKE                  October 2024

3.  Setup

   In order to use the extension specified in this document, a TLS
   client and server need to have pre-provisioned a password (or derived
   values as described by the desired PAKE protocol(s)).  The details of
   this pre-provisioned information are specific to each PAKE algorithm
   and are not specified here.

   Servers will of course have multiple instances of this configuration
   information for different clients.  Clients may also have multiple
   identities, even within a given server.

4.  PAKE Integration in TLS

   This section describes how the PAKE protocol is integrated and
   executed in the TLS handshake.

4.1.  Client Behavior

   To offer support for a PAKE protocol, the client sends a pake
   extension in the ClientHello carrying a PAKEClientHello value:

   enum {
       pake(0xTODO), (65535)
   } ExtensionType;

   The payload of the client extension has the following PAKEClientHello
   structure:

   enum {
       SPAKE2PLUS_V1 (0xXXXX),
   } NamedPAKE;

   struct {
       NamedPAKE   named_pake;
       opaque      client_identity<0..2^16-1>;
       opaque      server_identity<0..2^16-1>;
       opaque      pake_message<1..2^16-1>;
   } PAKEShare;

   struct {
       PAKEShare client_shares<0..2^16-1>;
   } PAKEClientHello;

   The PAKEClientHello structure is a list of PAKE algorithm and
   identity pairs under which the client can authenticate, and for each
   pair, the client's first message for the underlying PAKE protocol.
   Concretely, these structure fields are defined as follows:

Bauman, et al.            Expires 24 April 2025                 [Page 4]
Internet-Draft                TLS 1.3 PAKE                  October 2024

   client_shares  A list of PAKEShare values, each one with a distinct
      NamedPAKE algorithm.

   named_pake  The 2-byte identifier of the PAKE algorithm.

   client_identity  The client identity used for the PAKE.

   server_identity  The server identity used for the PAKE.

   pake_message  The client PAKE message used to initialize the
      protocol.

   The client MUST use the same client identity and server identity in
   each PAKEShare it sends to the server.  This is required to prevent
   client enumeration attacks; see Section 8.

   The NamedPAKE field in the PAKEShare allows implementations to
   support multiple PAKEs and negotiate which to use in the context of
   the handshake.  For instance, if a client knows a password but not
   which PAKE the server supports it could send corresponding PAKEShares
   for each PAKE.

   If a client sends the pake extension, then it MAY also send the
   key_share and pre_shared_key extensions, to allow the server to
   choose an authentication mode.  Unlike PSK-based authentication,
   however, authentication with PAKE cannot be combined with the normal
   TLS key exchange mechanism.  Forward secrecy is provided by the PAKE
   itself.

   The server identity value provided in the PAKEClientHello structure
   are disjoint from that which the client may provide in the
   ServerNameIndication (SNI) field.

4.2.  Server Behavior

   A server that receives a pake extension examines its contents to
   determine if it is well-formed.  In particular, if there are
   duplicate PAKEShare values in the PAKEClientHello structure, where a
   duplicate is defined as two PAKEShare values that share the same
   NamedPAKE, client identity, and server identity values, the server
   aborts the handshake with an "illegal_parameter" alert.  Moreover, if
   there are different client identity or server identity values carried
   in the PAKEShare values, the pake extension is considered to be
   malformed.  This check is done to prevent client enumeration attacks;
   see Section 8.

Bauman, et al.            Expires 24 April 2025                 [Page 5]
Internet-Draft                TLS 1.3 PAKE                  October 2024

   If the list of PAKEShare values is well-formed, the server then scans
   the list of PAKEShare values to determine if there is one that the
   server can use based on its local database of PAKE registration
   information.  If one does not exist, the server simulates a PAKE
   response as described in Section 4.4.  Simulating a response prevents
   client enumeration attacks on the server's PAKE database; see
   Section 8.  Otherwise, the server MUST abort the protocol with an
   "illegal_parameter" alert.

   If there exists a valid PAKE registration, the server indicates its
   selection by including a pake extension in its ServerHello.  The
   content of this extension is a PAKEServerHello value, specifying the
   PAKE and identity value for the registration record the server has
   selected, and the server's first message in the PAKE protocol.  The
   format of this structure is as follows:

   struct {
       PAKEShare server_share;
   } PAKEServerHello;

   The server_share value of this structure is a PAKEShare, which echoes
   back the PAKE algorithm chosen, the chosen client and server identity
   values, and the server's PAKE message generated in response to the
   client's PAKE message.

   If a server uses PAKE authentication, then it MUST NOT send an
   extension of type key_share, pre_shared_key, or early_data.

   Use of PAKE authentication is not compatible with standard
   certificate-based authentication of both clients and servers.  If use
   of a PAKE is negotiated, then servers MUST NOT include a Certificate
   or CertificateRequest message in the handshake.

4.3.  Key Schedule Modifications

   When the client and server agree on a PAKE to use, a shared secret
   derived from the PAKE protocol is used as the ECDH(E) input to the
   TLS 1.3 key schedule.  Details for the shared secret computation are
   left to the specific PAKE algorithm.  See Section 6 for information
   about how the SPAKE2+ variant operates.

   As with client authentication via certificates, the server has not
   authenticated the client until after it has received the client's
   Finished message.  When a server negotiates the use of this mechanism
   for authentication, it SHOULD NOT send application data before it has
   received the client's Finished message, as it would otherwise be
   sending data to an unauthenticated client.

Bauman, et al.            Expires 24 April 2025                 [Page 6]
Internet-Draft                TLS 1.3 PAKE                  October 2024

4.4.  Server Simulation

   To simulate a fake PAKE response, the server does the following:

   *  Select a random identity supplied by the client.

   *  Include the pake extension in its ServerHello, containing a
      PAKEShare value with the randomly selected identity and
      corresponding pake.  To generate the pake_message for this
      PAKEShare value, the server should select a value uniformly at
      random from the set of possible values of the PAKE algorithm
      shares.  For example, for SPAKE2+, this would be a random point on
      the elliptic curve group.

   *  Perform the rest of the protocol as normal.

   Because the server's share was selected uniformly at random, the
   server will reject the client's Finished message with overwhelming
   probability.

   A server that performs the simulation of the protocol acts only as an
   all-or-nothing oracle for whether a given (identity, password) pair
   is correct.  If an attacker does not supply a correct pair, they do
   not learn anything beyond this fact.

5.  Compatible PAKE Protocols

   In order to be usable with the pake extension, a PAKE protocol must
   specify some syntax for its messages, and the protocol itself must be
   compatible with the message flow described above.  A specification
   describing the use of a particular PAKE protocol with TLS must
   provide the following details:

   *  A NamedPAKE registered value indicating pre-provisioned
      parameters;

   *  Content of the pake_message field in a ClientHello;

   *  Content of the pake_message field in a ServerHello;

   *  How the PAKE protocol is executed based on those messages; and

   *  How the outputs of the PAKE protocol are used to populate the
      (EC)DHE input to the TLS key schedule.

   In addition, to be compatible with the security requirements of TLS
   1.3, PAKE protocols defined for use with TLS 1.3 MUST provide forward
   secrecy.

Bauman, et al.            Expires 24 April 2025                 [Page 7]
Internet-Draft                TLS 1.3 PAKE                  October 2024

   Several current PAKE protocols satisfy these requirements, for
   example:

   *  CPace [CPACE]

   *  SPAKE2+ (described in Section 6) [RFC9383]

   *  OPAQUE [OPAQUE]

6.  SPAKE2+ Integration

   This section describes the SPAKE2+ instantiation of the pake
   extension for TLS.  The SPAKE2+ protocol is described in
   [SPAKE2PLUS].  Section 6.1 describes the setup required before the
   protocol runs, and Section 6.2 describes the protocol execution in
   TLS.

6.1.  Protocol Setup

   The TLS client and server roles map to the Prover and Verifier roles
   in the SPAKE2+ specification, respectively.  Clients are configured
   with a client identity, server identity, and password verifier (w0
   and w1 according to [SPAKE2PLUS]).  Similarly, servers are configured
   with a list of client identity, server identity, and password
   registration values (w0 and L according to [SPAKE2PLUS]).  Servers
   use this list when completing the SPAKE2+ protocol.  The values for
   the password verifiers and registration records (w0, w1, and L) are
   not specified here; see Section 3.2 of [SPAKE2PLUS] for more
   information.

   The NamedPake value for SPAKE2+ fully defines the parameters
   associated with the protocol, including the prime-order group G,
   cryptographic hash function Hash, key derivation function KDF, and
   message authentication code MAC.  Additionally, the NamedPake value
   for SPAKE2+ fully defines the constants for M and N as needed for the
   protocol; see Section 4 of [SPAKE2PLUS].

6.2.  Protocol Execution

   The content of one PAKEShare value in the PAKEClientHello structure
   consists of the NamedPAKE value SPAKE2PLUS_V1, the client and server
   identities the client was configured with, and the value shareP as
   computed in Section 3.3 of [SPAKE2PLUS].

Bauman, et al.            Expires 24 April 2025                 [Page 8]
Internet-Draft                TLS 1.3 PAKE                  October 2024

   The content of the server PAKEShare value in the PAKEServerHello
   structure consists of the NamedPAKE value SPAKE2PLUS_V1 and the
   client and server identities chosen from the PAKEClientHello list of
   PAKEShare values, as well as the value shareV as computed in
   Section 3.3 of [SPAKE2PLUS].

   Given shareP and shareV, the client and server can then both compute
   K_main, the root secret in the protocol as described in Section 3.4
   of [SPAKE2PLUS].  The "Context" value for SPAKE2+ is "TLS-
   SPAKE2PLUS_V1".  The rest of the values needed for the transcript
   derivation are as configured in Section 6.1, exchanged over the wire,
   or computed by client and server.

   Using K_main, the client and server both compute confirmP and
   confirmV values (for key confirmation).  These are then concatenated
   and then used as input to the TLS 1.3 key schedule.  Specifically,
   they use confirmP || confirmV as the (EC)DHE input to the key
   schedule in Section 7.1 of [TLS13], as shown below.

                                       0
                                       |
                                       v
                         PSK ->  HKDF-Extract = Early Secret
                                       |
                                       +-----> Derive-Secret(...)
                                       +-----> Derive-Secret(...)
                                       +-----> Derive-Secret(...)
                                       |
                                       v
                                 Derive-Secret(., "derived", "")
                                       |
                                       v
                     K_shared -> HKDF-Extract = Handshake Secret
                     ^^^^^^^^          |
                                       +-----> Derive-Secret(...)
                                       +-----> Derive-Secret(...)
                                       |
                                       v
                                 Derive-Secret(., "derived", "")
                                       |
                                       v
                            0 -> HKDF-Extract = Master Secret
                                       |
                                       +-----> Derive-Secret(...)
                                       +-----> Derive-Secret(...)
                                       +-----> Derive-Secret(...)
                                       +-----> Derive-Secret(...)

Bauman, et al.            Expires 24 April 2025                 [Page 9]
Internet-Draft                TLS 1.3 PAKE                  October 2024

   Note that the client and server do not additionally compute or verify
   the key confirmation messages as described in Section 3.4 of
   [SPAKE2PLUS].  See Section 8.1 for more information about the safety
   of this approach.

7.  Privacy Considerations

   Client and server identities are sent in the clear in the
   PAKEClientHello extension.  While normally the TLS server identity is
   already in the clear -- carried in the SNI extension -- TLS client
   identities are encrypted under the TLS handshake secrets.  Thus, the
   PAKEClientHello extension reveals more information to a passive
   network attacker than normal, mutually-authenticated TLS handshakes.

   The implications of leaking the client identity to a passive network
   attacker vary.  For instance, a successful TLS handshake after
   negotiating use of a PAKE indicates that the chosen client identity
   is valid.  This is relevant in settings where client enumeration may
   be a concern.

   Applications for which this leak is a problem can use the TLS
   Encrypted ClientHello (ECH) extension to encrypt the PAKEClientHello
   extension in transit to the server [ECH].

8.  Security Considerations

   Many of the security properties of this protocol will derive from the
   PAKE protocol being used.  Security considerations for PAKE protocols
   are noted in Section 5.

   If a server doesn't recognize any of the identities supplied by the
   client in the ClientHello pake extension, the server MAY abort the
   handshake with an "illegal_parameter" alert.  In this case, the
   server acts as an oracle for identities, in which each handshake
   allows an attacker to learn whether the server recognizes any of the
   identities in a set.

   Alternatively, if the server wishes to hide the fact that these
   client identities are unrecognized, the server MAY simulate the
   protocol as if an identity was recognized, but then reject the
   client's Finished message with a "decrypt_error" alert, as if the
   password was incorrect.  This is similar to the procedure outlined in
   [RFC5054].  The simulation mechanism is described in Section 4.4.

Bauman, et al.            Expires 24 April 2025                [Page 10]
Internet-Draft                TLS 1.3 PAKE                  October 2024

8.1.  SPAKE2+ Security Considerations

   Section 6 describes how to integrate SPAKE2+ into TLS using the pake
   extension in this document.  This integration deviates from the
   SPAKE2+ protocol in [SPAKE2PLUS] in one important way: the explicit
   key confirmation checks required in [SPAKE2PLUS] are replaced with
   the TLS Finished messages.  This is because the TLS Finished messages
   compute a MAC over the TLS transcript, which includes both the shareP
   and shareV values exchanged for SPAKE2+.

   [[OPEN ISSUE: this requires formal analysis to confirm.]]

9.  IANA Considerations

   This document requests that IANA add a value to the TLS ExtensionType
   Registry with the following contents:

          +========+================+=========+=================+
          | Value  | Extension Name | TLS 1.3 |    Reference    |
          +========+================+=========+=================+
          | 0xTODO | pake           |  CH, SH | (this document) |
          +--------+----------------+---------+-----------------+

                                  Table 1

   [[ RFC EDITOR: Please replace "TODO" in the above table with the
   value assigned by IANA, and replace "(this document)" with the RFC
   number assigned to this document. ]]

9.1.  Named PAKE registry

   This document requests that IANA create a new registry called "Named
   PAKE Algorithms" with the following contents:

           +========+===============+=================+=======+
           | Value  | Named PAKE    |    Reference    | Notes |
           +========+===============+=================+=======+
           | 0xTODO | SPAKE2PLUS_V1 | (this document) | N/A   |
           +--------+---------------+-----------------+-------+

                                 Table 2

   The SPAKE2PLUS_V1 NamedPAKE variant has the following parameters
   associated with it:

   *  G: P-256

   *  Hash: SHA256

Bauman, et al.            Expires 24 April 2025                [Page 11]
Internet-Draft                TLS 1.3 PAKE                  October 2024

   *  KDF: HKDF-SHA256

   *  MAC: HMAC-SHA256

   Additionally, it uses the M and N values from Section 4 of
   [SPAKE2PLUS], included below, as compressed points on the P-256
   curve, for completeness.

   M =
   02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f

   N =
   03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49

10.  References

10.1.  Normative References

   [CPACE]    Abdalla, M., Haase, B., and J. Hesse, "CPace, a balanced
              composable PAKE", Work in Progress, Internet-Draft, draft-
              irtf-cfrg-cpace-13, 14 October 2024,
              <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
              cpace-13>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC9147]  Rescorla, E., Tschofenig, H., and N. Modadugu, "The
              Datagram Transport Layer Security (DTLS) Protocol Version
              1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
              <https://www.rfc-editor.org/rfc/rfc9147>.

   [RFC9383]  Taubert, T. and C. A. Wood, "SPAKE2+, an Augmented
              Password-Authenticated Key Exchange (PAKE) Protocol",
              RFC 9383, DOI 10.17487/RFC9383, September 2023,
              <https://www.rfc-editor.org/rfc/rfc9383>.

   [SPAKE2PLUS]
              Taubert, T. and C. A. Wood, "SPAKE2+, an Augmented
              Password-Authenticated Key Exchange (PAKE) Protocol",
              RFC 9383, DOI 10.17487/RFC9383, September 2023,
              <https://www.rfc-editor.org/rfc/rfc9383>.

Bauman, et al.            Expires 24 April 2025                [Page 12]
Internet-Draft                TLS 1.3 PAKE                  October 2024

   [TLS13]    Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/rfc/rfc8446>.

10.2.  Informative References

   [ECH]      Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
              Encrypted Client Hello", Work in Progress, Internet-Draft,
              draft-ietf-tls-esni-22, 15 September 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
              esni-22>.

   [OPAQUE]   Bourdrez, D., Krawczyk, H., Lewi, K., and C. A. Wood, "The
              OPAQUE Augmented PAKE Protocol", Work in Progress,
              Internet-Draft, draft-irtf-cfrg-opaque-17, 27 September
              2024, <https://datatracker.ietf.org/doc/html/draft-irtf-
              cfrg-opaque-17>.

   [RFC5054]  Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
              "Using the Secure Remote Password (SRP) Protocol for TLS
              Authentication", RFC 5054, DOI 10.17487/RFC5054, November
              2007, <https://www.rfc-editor.org/rfc/rfc5054>.

Authors' Addresses

   Laura Bauman
   Apple, Inc.
   Email: l_bauman@apple.com

   Samir Menon
   Apple, Inc.
   Email: samir_menon@apple.com

   Christopher A. Wood
   Apple, Inc.
   Email: caw@heapingbits.net

Bauman, et al.            Expires 24 April 2025                [Page 13]