LURK D. Migault Internet-Draft Ericsson Intended status: Standards Track July 02, 2018 Expires: January 3, 2019 LURK Extension version 1 for (D)TLS 1.3 Authentication draft-mglt-lurk-tls13-00 Abstract This document describes the LURK Extension 'tls13' which enables interactions between a LURK Client and a LURK Server in a context of authentication with (D)TLS 1.3. 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 January 3, 2019. Copyright Notice Copyright (c) 2018 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Migault Expires January 3, 2019 [Page 1] Internet-Draft LURK/TLS 1.3 July 2018 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. LURK Header . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. handshake_server_key . . . . . . . . . . . . . . . . . . . . 4 3.1. Request Payload . . . . . . . . . . . . . . . . . . . . . 5 3.2. Response Payload . . . . . . . . . . . . . . . . . . . . 6 3.3. LURK Client Behavior . . . . . . . . . . . . . . . . . . 6 3.4. LURK Server Behavior . . . . . . . . . . . . . . . . . . 7 4. auth . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Request Payload . . . . . . . . . . . . . . . . . . . . . 9 4.2. Response Payload . . . . . . . . . . . . . . . . . . . . 10 4.3. LURK Client Behavior (TLS Server) . . . . . . . . . . . . 10 4.4. LURK Client Behavior (TLS Client) . . . . . . . . . . . . 12 4.4.1. Local Ticket . . . . . . . . . . . . . . . . . . . . 13 4.5. LURK Server Behavior . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. Normative References . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction This document defines a LURK extension for TLS 1.3. This document assume s the reader is familiar with [I-D.mglt-lurk-lurk] that describes the LURK architecture as well as the LURK Protocol and the integration of the LURK extensions. The motivations for the LURK Extension TLS 1.3 are similar to those for the LURK extension of TLS 1.2 [I-D.mglt-lurk-tls12]. LURK defines an interface to a Cryptographic Service that stores the security credentials - Typically the PSKs and private keys. Interactions with the Cryptographic Service can be performed by the TLS Client as well as by the TLS Server. The TLS Server expects from the Cryptographic Service: o To retrieve the necessary keys to complete the handshake. This typically includes the [sender]_handshake_traffic_secret to generate the keys necessary to encrypt the handshake extensions and messages, the [sender]_application_traffic_secret_N keys to protect the application data or the exporter_master_secret when needed. o To generate of Handshake message or extensions that authenticate the TLS Server. This typically includes the CertificateVerify and Finished message. Migault Expires January 3, 2019 [Page 2] Internet-Draft LURK/TLS 1.3 July 2018 o To retrieve NewSessionTicket to enable the TLS Client to perform session resumption. The TLS Client expetcs from the Cryptographic Service: o To retrieve the necessary keys to complete the handshake. o To "provision" resumption_master_secret, so the PSK can be used when the TLS Client is using session resumption using a NewSession ticket. o To generate of Handshake message or extensions that authenticate the TLS Client. This typically includes the CertificateVerify and Finished message. Note that the TLS Server MAY interact with a single exchange with the Cryptographic Service, the TLS Client is expected to retrieve the [sender]_handshake_traffic_secret to generate the keys encrypt the handshake extensions and messages to decrypt the messages/extensions received from the TLS Server, prior to request for the generation of the CertificateVerify or Finished message. 2. LURK Header LURK / TLS 1.3 is a LURK Extension that introduces a new designation "tls13". This document assumes that Extension is defined with designation set to "tls13" and version set to 1. The LURK Extension extends the LURKHeader structure defined in [I-D.mglt-lurk-lurk] as follows: Migault Expires January 3, 2019 [Page 3] Internet-Draft LURK/TLS 1.3 July 2018 enum { tls13 (2), (255) } Designation; enum { capabilities (0), ping (1), rsa_master (2), rsa_extended_master (3), ecdhe (4), (255) }TLS13Type; enum { // generic values reserved or aligned with the // LURK Protocol request (0), success (1), undefined_error (2), invalid_payload_format (3), //code points for ecdhe authentication invalid_ec_type (9), invalid_ec_curve (10), invalid_poo_prf (11), invalid_poo (12), (255) }TLS13Status struct { Designation designation = "tls12"; int8 version = 1; } Extension; struct { Extension extension; select( Extension ){ case ("tls13", 1): TLS12Type; } type; select( Extension ){ case ("tls13", 1): TLS13Status; } status; uint64 id; unint32 length; } LURKHeader; 3. handshake_server_key This exchange is only expected to be performed by a TLS Client. The server_handshake_key is necessary for the TLS Client to decrypt the handshake message/extensions encrypted by the TLS Server. Interaction with a Cryptographic Service MAY be required when the PSK is protected by the Cryptographic Service. Migault Expires January 3, 2019 [Page 4] Internet-Draft LURK/TLS 1.3 July 2018 3.1. Request Payload enum { sha256 (0), (255) } TranscriptHash; enum { psk_raw (0), psk_ticket (1), (255) } PSKType struct { PSKType psk_type; select( psk_type ){ case raw_psk : opaque raw_psk<0..2^16-1>; case identity_psk : OfferedPsks offered_psk // {{I-D.ietf-tls-tls13}} section 4.2.11 } PSK struct { select ( ke_mode ){ // {{I-D.ietf-tls-tls13}} section 4.2.9 case psk_ke : PSK psk case psk_dhe_ke : PSK psk NamedGroup dh_group; // {{I-D.ietf-tls-tls13}} section 4.2.7 opaque dhe_secret<1..2^16-1>; } } KeyScheduleInputSecrets enum { sha256 (0) (255) } PFSAlgorithm struct { PFSAlgorithm pfs; // {{I-D.mglt-lurk-tls12}} section 4.1 TranscriptHash h; PskKeyExchangeMode ke_mode // {{I-D.ietf-tls-tls13}} section 4.2.9 opaque handshake_context<0..2^32-1> KeyScheduleInputSecrets secrets } HandshakeServerKeyRequest psk_type indicates how the PSK is provisioned to initiate the key schedule as described in [I-D.ietf-tls-tls13] section 7.1. The type psk_raw indicates the PSK is explicitly provided. The type psk_ticket indicates the PSK is generated from the ticket as described in [I-D.ietf-tls-tls13] section 4.6.1. pfs the one-way hash function (OWHF) used by LURK to implement Perfect Forward Secrecy. Migault Expires January 3, 2019 [Page 5] Internet-Draft LURK/TLS 1.3 July 2018 h the hash function used by the Transcript-Hash [I-D.ietf-tls-tls13] section 4.4.1. offered_psk reuses the OfferedPsks described in [I-D.ietf-tls-tls13] section 4.2.11. The PSK structure only allow a single PSK, thus OfferedPsks MUST represent a single PSK. ke_mode defines pre shared key exchange defined in [I-D.ietf-tls-tls13] section 4.2.9. It indicates whether the key exchange considers a (EC)DHE key establishment or not in addition to the PSK. dh_group reuses the structure NamedGroup of [I-D.ietf-tls-tls13] section 4.2.7 to indicate the curve or the group used in (EC)DHE key establishment. handshake_context the necessary handshake context to generate the key as described in [I-D.ietf-tls-tls13] section 7.1. The handshake_context MUST be ClientHello...ServerHello. secrets the necessary secret inputs (PSK, (EC)DHE) secret necessary for the key schedule of [I-D.ietf-tls-tls13] section 7.1. 3.2. Response Payload struct { opaque server_handshake_key<0..2^32-1> } HandshakeServerKeyResponse server_handshake_key the server_handshake_key 3.3. LURK Client Behavior The TLS Client establishing a TLS session with a TLS Server receives from the TLS Server a ServerHello message with additional encrypted messages such as the EncryptedExtensions, the Finished as well as the optional Certificate, CertificateVerify and Application Data message. The TLS Client needs to retrieve the server_handshake_key in order to decrypt these messages. With ServerHello as the input message, the LURK Client initiates the exchange as described below: Perfect Forward Secrecy Setting: o Perfect Forward Secrecy is performed as described in [I-D.mglt-lurk-tls12] section 4.1.1 over the client_random. There is no gmt_unix_time as such ServerHello.random is generated as Migault Expires January 3, 2019 [Page 6] Internet-Draft LURK/TLS 1.3 July 2018 follows: ~~~ ClientHello.random = pfs( client_random + "tls13_c pfs" ); ~~~ Transcript Hash Setting: o the value for transcript hash is provided by the configuration. PSK Key Exchange Mode Setting: o if the input message does not contains any key_share extension, the LURK Client sets ke_mode to psk_ke. o if a key_share extension is present the LURK Client sets ke_mode to psk_dhe_ke. Key Schedule Input Secret Setting: o if the input message has no pre_shared_key extension, the LURK Client sets psk_type to psk_raw with a psk of length 0. o if the input message has a pre_shared_key extension, the LURK Client provides the PSK that is not a PSK of zero length, as follows: ..* the PSK is provided explicitly by using the psk_type set to psk_raw with the explicit value of the PSK. This alternative is NOT RECOMMENDED, as it means the PSK is not known by the Cryptographic Service and is known outside this service. It may happen when the TLS Client is configured with a PSK while the Cryptographic Service is not provisioned with that PSK. The case where the PSK is provided for a session resumption is outside the scope of this document as the session_resumption_secret is never shared outside the Cryptographic Service. ..* the PSK is provided via NewSessionTicket. Upon receiving a selected_identity in the pre_shared_key extension, the LURK Client selects the corresponding local_ticket previously provided by the LURK Server during the previous handshake. local_ticket are internal structure used by LURK detailled in Section 4.4.1 3.4. LURK Server Behavior Upon receiving a handshake_server_key request, the LURK server proceeds as follows: Perfect Forward Secrecy Check: o if pfs is not supported, an invalid_pfs erroro is returned. o ClientHello.random is generated as described in Section 3.3 and the value is provided in handshake_context. Migault Expires January 3, 2019 [Page 7] Internet-Draft LURK/TLS 1.3 July 2018 Transcript-Hash Check: o if h is not a supported transcript-hash function and invalid_transcript_hash error is returned. Handshake Check: o if handshake does not contains a ClientHello...ServerHello an invalid_handshake error is returned. PSKExchangeMode Check: o if ke_mode is not supported an invalid_ke_mode error is returned. KeyScheduleInputSecret Check check the validity of the secrets as well as the coherence wit the pre shared key exchange. These checking operations are subdivided into (EC)DHE Check and PSK Check operations: (EC)DHE Check: o if ke_mode is set to psk_dhe_ke and secret does not contain a (EC)DHE secret an invalid_secret error is returned. o if the (EC)DHE secret does not match the expected length or the curve is not supported an invalid_ecdhe_secret error is returned. PSK Check: o if the psk type is not supported a invalid_psk_type is returned. o if psk_type is psk_raw and the format of the psk is unexpected an invalid_psk_format error is returned. o if the psk_type is psk_ticket: ..* if the number of psk or associated binder is more than 1, an invalid_ticket_format error is returned ..* there is no corresponding identity, an invalid_psk_ticket error is returned. * if the psk_type is identity_psk binder_key is generated as described in [I-D.ietf-tls-tls13] section 7.1. ..* if the binder associated to the psk does not match the one provided in the offered_psk and invalid_binder error is returned. The binder is computed as described in [I-D.ietf-tls-tls13] section 4.2.11.2. with the binder_key generated as described in [I-D.ietf-tls-tls13] section 7.1. Key Generation: Migault Expires January 3, 2019 [Page 8] Internet-Draft LURK/TLS 1.3 July 2018 o server_handshake_key is generated as described in [I-D.ietf-tls-tls13] section 7.1 and returned to the LURK Client. 4. auth This exchange provides interactions with a Cryptographic Service both on the TLS Client side as well as the TLS Server side. 4.1. Request Payload enum { server (0), client (1), post-handshake (2) } HandshakeMode; struct { PFSAlgorithm pfs; // {{I-D.mglt-lurk-tls12}} section 4.1 TranscriptHash h; // c, f PskKeyExchangeMode ke_mode // {{I-D.ietf-tls-tls13}} section 4.2.9 select( ke_mode ){ case : psk_dhe_ke Certificate certificate // {{I-D.ietf-tls-tls13}} section 4.4.2 SignatureScheme algorithm // {{I-D.ietf-tls-tls13}} section 4.2.3. } HandshakeMode handshake_mode // c, f opaque handshake_context<0..2^32-1> // c, f KeyScheduleInputSecrets secrets // f uint8 key_request uint8 ticket_number } AuthRequest c: structure used for the CertificateVerify message f: structure used for the Finished message pfs, h, ke_mode, handshake_context and secrets are define in Section 3.1 certificate end point certificate defined in [I-D.ietf-tls-tls13] section 4.4.2. algorithm signature algorithm used defined in [I-D.ietf-tls-tls13] section 4.2.3. handshake_mode defines the specific Handshake Context and Base Key necessary to compute authentication messages as defined in [I-D.ietf-tls-tls13] section 4.4. The handshake_mode set to server indicates the LURK exchange is performed by the TLS Server while the handshake_mode set to client or post-handshake indicates the LURK exchange is performed by the TLS Client. Migault Expires January 3, 2019 [Page 9] Internet-Draft LURK/TLS 1.3 July 2018 handshake_context Handshake Context has defined in [I-D.ietf-tls-tls13] section 4.4. key_request indicates optional requested keys. The bit is set to 1 to indicate the key is being requested by the LURK Client. ..* bit 0 : client_handshake_traffic_secret ..* bit 1 : server_handshake_traffic_secret ..* bit 2 : client_application_traffic_secret_0 ..* bit 3 : server_application_traffic_secret_0 ..* bit 4 : exporter_master_secret ..* bit 5-7: set to 0 ticket_number indicates the expected number of session resumption tickets. When requested by the TLS Client the ticket_number is expected to be 0 or 1. When requested by the TLS Server the number can be larger. 4.2. Response Payload struct{ opaque key<0..2^16-1> } Key struct { uint8 key_index opaque key_list<0..2^32-1> } Keys struct { Keys keys CertificateVerify certificate_verify Finished finished NewSessionTicket ticket_list<0..2^32-1> } AuthResponse key_index follows the same syntax as key_request in Section 4.1. key_list :the list of keys indicated by key_index. ticket_list list of NewTicketSessions 4.3. LURK Client Behavior (TLS Server) On a TLS Server, the LURK Server initiates the LURK exchange after receiving the ClientHello from the TLS Client. The purpose of this exchange is to retrieve the CertificateVerify, Finished, and the necessary keys to: Migault Expires January 3, 2019 [Page 10] Internet-Draft LURK/TLS 1.3 July 2018 o encrypt the EncryptedExtensions, Finished and optional CertificateRequest Certificate and CertificateVerify message: server_handshake_traffic_secret o encrypt the optional Application Data message: server__application_traffic_secret_N o decrypt the future Finished or optional Certificate and CertificateVerify message sent by the TLS Client: client_handshake_traffic_secret. o decrypt the future Application Data message with the client__application_traffic_secret_N Perfect Forward Secrecy Setting: o Perfect Forward Secrecy is performed as described in [I-D.mglt-lurk-tls12] section 4.1.1 over the server_random. There is no gmt_unix_time as such ServerHello.random is generated as follows: ~~~ ServerHello.random = pfs( server_random + "tls13_s pfs" ); ~~~ The LURK Client proceeds to the Transcript Hash Setting PSK Key Exchange Mode Setting and the Key Schedule Input Secret Setting as described in Section 3.3. Handshake Mode Setting: o If the LURK Client sets the handshake_mode to "server". Handshake Setting: The handshake is set as described in [I-D.ietf-tls-tls13] section 4.4. Key Request Setting: o key_request MUST have the Bit 0 and Bit 1 set to retrieve the [sender]_handshake_traffic_secret. o key_request MUST have the Bit 2 and Bit 3 set to retrieve the [sender]_application_traffic_secret_N o Key_request MAY have Bit 4 set if there is a need to use the extractor. Upon receiving the AuthResponse, the TLS Server encrypts the messages and pursue the TLS handshake as defined in [I-D.ietf-tls-tls13]. Migault Expires January 3, 2019 [Page 11] Internet-Draft LURK/TLS 1.3 July 2018 4.4. LURK Client Behavior (TLS Client) On a TLS Client the LURK Client initiates an AuthRequest in order to compute the Finished and optional CertificateVerify as well as to retrieve the necessary keys to: o encrypt the Finished and optional Certificate and CertificateVerify message: client_handshake_traffic_secret o encrypt the optional Application Data message: server__application_traffic_secret_N o decrypt the future Application Data message with the server__application_traffic_secret_N The TLS Client has decrypted the encrypted handshake messages sent by the TLS Server by retrieving the server_handshake_traffic_secret with an HandshakeServerKeyRequest. The LURK Client proceeds to Perfect Forward Secrecy Setting, Transcript Hash Setting, Key Schedule Input Secret Setting as described in Section 3.3. If the TLS Client has received a CertificateRequest from the TLS Server, the LURK Client: o sets the ke_mode to psk_dhe_ke. Note that the value is not correlated to the value agreed psk_key_exchange_modes between the TLS Client and the TLS Server. Instead it indicates the necessity to generate a CertificateVerify. o provides the Certificate associated to the private key of the TLS Handshake Mode Setting: o If the LURK Client is initiating a LURK exchange on behalf of a TLS Client it sets the handshake_mode to: ..* "client" when the LURK exchange occurs during the TLS handshake. ..* "post- authentication" when the LURK exchange occurs outside the TLS handshake. Handshake Setting: o set handshake_context as defined in [I-D.ietf-tls-tls13] section 4.4. Key Request Setting: Migault Expires January 3, 2019 [Page 12] Internet-Draft LURK/TLS 1.3 July 2018 o key_request SHOULD have the Bit 0 unset, as client_handshake_traffic_secret is already known by the TLS Client o key_request MUST have the Bit 1 set to retrieve the server_handshake_traffic_secret. o key_request MUST have the Bit 2 and Bit 3 set to retrieve the [sender]_application_traffic_secret_N o Key_request MAY have Bit 4 set if there is a need to use the extractor. Ticket Number Setting: o If the TLS Client want to performed further session resumption, ticket_number is set to 1 and 0 otherwise. Upon receiving the AuthResponse, the LURK Client has the necessary information to proceed the TLS handshake. The ticket_list is a list of local_ticket. The list MUST have a maximum of one local_ticket. The LURK Client is expected to manage the local_tickets as described in Section 4.4.1 4.4.1. Local Ticket local_ticket re-uses the NewSessionTicket structure in two different ways depending if the LURK exchange is initiated by a TLS Client or by a TLS Server. o ticket provided to the TLS Server (by the LURK Server) are new_session_ticket, expected to be forwarded to the TLS Client. o tickets provided to the TLS Client ( by the LURK Server) are local_ticket. These local_tickets are only expected to be used between the LURK Client and the LURK Server of the TLS Client. During the initial handshake, the TLS Client has received a local_ticket from the LURK Server and a new_session_ticket from the TLS Server. The TLS Client updates the local_ticket as follows: the ticket_nonce and extensions fields of the new_session_ticket are copied to the local_ticket. When the TLS Server provides more than one new_session_ticket tickets, these tickets are expected to have different nonce. On the other hand a single local_ticket will be provided by the LURK Server. The TLS Client generates an associated local_ticket for each new_session_ticket. All of them are generated from the local_ticket provided by the LURK Server. Migault Expires January 3, 2019 [Page 13] Internet-Draft LURK/TLS 1.3 July 2018 Though the new_Session_ticket and the local_ticket have different meanings, a TLS Client will not be able to perform session resumption without the corresponding local_ticket. More specifically, the TLS Client MUST: o remove local_tickets and new_session_tickets that have expired o remove local_tickets that have no associated new_session_tickets o remove new_session_tickets that have no associated local_tickets In all these cases, a new handshake will be renegotiated. Note that this gives the Cryptographic Service the ability to define the maximum time a new_session_ticket can be used. 4.5. LURK Server Behavior Upon receiving a handshake_server_key request, the LURK server proceeds as follows: Perfect Forward Secrecy Check is performed as Section 3.3 using the pfs, and client_random (resp. server_random) as described in Section 3.3 (resp. Section 4.3). Transcript-Hash Check, PSKExchangeMode Check, KeyScheduleInputSecrets Check are performed as described in Section 3.4 HandshakeMode Check: o if the mode is not supported a invalid_handshake_mode error is returned. This typically prevents a TLS Client to perform computation expected to happen on the TLS Server, or to distinguish and authorize client authentication performed during the handshake or post handshake. Handshake Check: o if the hanshake_context does not match the expected handshake context as defined in [I-D.ietf-tls-tls13] section 4.4. an invalid_handshake error is returned. CertificateVerify Check: o if ke_mode is set to psk_dhe_ke and the certificate is not supported an invalid_certificate error is returned o if ke_mode is set to psk_dhe_ke and the algorithm is not supported an invalid_signature_scheme error is returned Migault Expires January 3, 2019 [Page 14] Internet-Draft LURK/TLS 1.3 July 2018 Keys are generated as described in [I-D.ietf-tls-tls13] section 7.1. This includes the Base Key use to generate the Finished messages as well as the resumption_master_secret. key_request is indicative and is used by the LURK Client to indicate the keys that are not necessarily needed in order to save bandwidth. The LURK Server SHOULD NOT responds with keys whose key_request bit is unset. The CertificateVerify message is generated as described in [I-D.ietf-tls-tls13] section 4.4.3. The Finished message is generated as described in [I-D.ietf-tls-tls13] section 4.4.4. ticket_number indicates the number of NewSessionTicket. ticket_session have different meaning when used by the TLS Client or the TLS Server. When the LURK exchange is initiated by the LURK Client, the ticket_sessions are local_ticket and are only expected to be used between the LURK Client and the LURK Server. Such local_ticket avoids a direct communication of the resumption_master_secret. local_ticket follows the definition of new_session_tickets described in [I-D.ietf-tls-tls13] section 4.6.1. The LURK Server MUST have a zero length ticket_nonce and zero length extensions When the LURK exchange is initiated by the TLS Server the tickets are new_session_tickets as described in [I-D.ietf-tls-tls13] section 4.6.1. As a result: o if handshake_mode is set to server, the LURK Server SHOULD respond with a list of new_session_tickets that is not greater than the number indicated by ticket_number. The number of ticket MAY be defined by the LURK Server policies. o if handshake_mode is set to client or post-handshake the LURK Server SHOULD respond with a list of local_ticket that is not greater than the number indicated by ticket_number. The list MUST NOT exceed one local_ticket. 5. Security Considerations 6. IANA Considerations Migault Expires January 3, 2019 [Page 15] Internet-Draft LURK/TLS 1.3 July 2018 7. Acknowledgments 8. Normative References [I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-28 (work in progress), March 2018. [I-D.mglt-lurk-lurk] Migault, D., "LURK Protocol version 1", draft-mglt-lurk- lurk-00 (work in progress), February 2018. [I-D.mglt-lurk-tls12] Migault, D., "LURK Extension version 1 for (D)TLS 1.2 and (D)TLS 1.1 Authentication", draft-mglt-lurk-tls12-00 (work in progress), February 2018. Author's Address Daniel Migault Ericsson 8275 Trans Canada Route Saint Laurent, QC 4S 0B6 Canada EMail: daniel.migault@ericsson.com Migault Expires January 3, 2019 [Page 16]