[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 draft-ietf-emu-eap-tls13

Network Working Group                                        J. Mattsson
Internet-Draft                                                  M. Sethi
Obsoletes: 5216 (if approved)                                   Ericsson
Intended status: Standards Track                            July 3, 2017
Expires: January 4, 2018


                  The EAP-TLS Authentication Protocol
                      draft-mattsson-eap-tls13-00

Abstract

   Extensible Authentication Protocol (EAP) provides support for
   multiple authentication methods.  Transport Layer Security (TLS)
   provides mutual authentication, integrity-protected cipher suite
   negotiation, and key exchange between two endpoints.  This document
   specifies an EAP authentication method to provide support for
   certificate-based mutual authentication and key derivation using the
   version 1.3 of the TLS protocol.  This document obsoletes RFC5216.

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 http://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 4, 2018.

Copyright Notice

   Copyright (c) 2017 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
   (http://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



Mattsson & Sethi         Expires January 4, 2018                [Page 1]


Internet-Draft                 EAP-TLS 1.3                     July 2017


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Base Case . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Resumption  . . . . . . . . . . . . . . . . . . . . . . .   6
     3.3.  Termination . . . . . . . . . . . . . . . . . . . . . . .   8
     3.4.  Fragmentation . . . . . . . . . . . . . . . . . . . . . .   8
     3.5.  Key Heirarchy . . . . . . . . . . . . . . . . . . . . . .   9
     3.6.  Ciphersuite and Compression Negotiation . . . . . . . . .  10
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     4.1.  EAP security claims . . . . . . . . . . . . . . . . . . .  10
     4.2.  Certificate Validation and Revocation Checks  . . . . . .  11
   5.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  12
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     7.2.  Informative references  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   The Extensible Authentication Protocol (EAP) [RFC3748], provides a
   standard mechanism for supporting multiple authentication methods.
   Authentication methods such as Generalized Pre-Shared Key (GPSK)
   [RFC5433] and Protected One-Time Password Protocol (POTP) [RFC4793]
   have been defined using the EAP framework.  Specifications for how
   EAP messages are carried over a variety of lower layers such as
   Point-to-Point Protocol (PPP) [RFC1661], IEEE 802 wired networks
   [IEEE-802.1X], and wireless technologies such as IEEE 802.11
   [IEEE-802.11] and IEEE 802.16 [IEEE-802.16e] also exist.

   [RFC5216] had defined TLS based mutual authentication for EAP.  This
   document obsoletes [RFC5216] and specifies EAP-TLS that is based on
   TLS version 1.3.  TLS 1.3 obsoletes the older version 1.2 and
   introduces a number of changes such as encrypting all messages after
   ServerHello and adding a 0-RTT mode that saves a round-trip at
   connection setup.  For a complete list of updates see
   [I-D.ietf-tls-tls13].  This document does not request a new EAP
   method type assignment.






Mattsson & Sethi         Expires January 4, 2018                [Page 2]


Internet-Draft                 EAP-TLS 1.3                     July 2017


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   In addition, this document frequently uses the following terms as
   defined in :

   authenticator  The entity initiating EAP authentication.

   peer  The entity that responds to the authenticator.  In
         [IEEE-802.1X], this entity is known as the supplicant.

   server  The entity that terminates the EAP authentication method with
         the peer.  In the case where no backend authentication server
         is used, the EAP server is part of the authenticator.  In the
         case where the authenticator operates in pass-through mode, the
         EAP server is located on the backend authentication server.

   NAI   A Network Access Identifier [RFC7542].  It is the user
         identifier submitted by the peer/supplicant prior to accessing
         resources.

   Master Session Key (MSK)  Keying material that is derived between the
         EAP peer and server and exported by the EAP method.

   Extended Master Session Key (EMSK)  Additional keying material
         derived between the EAP peer and server that is exported by the
         EAP method.

3.  Protocol Overview

   The EAP-TLS conversation begins with the authenticator and the peer
   negotiating EAP.  The authenticator then sends an EAP-Request/
   Identity packet to the peer.  The peer then responds with its Network
   Access Identifier (NAI) in an EAP-Response/Identity packet.  From
   this point onwards, although nominally the EAP conversation occurs
   between the EAP peer and the EAP authenticator, the EAP server is the
   ultimate endpoint conversing with the EAP peer.  The authenticator
   MAY act as a pass-through to a backend EAP server.  In the case where
   no backend authentication server is used, the EAP server is part of
   the authenticator.








Mattsson & Sethi         Expires January 4, 2018                [Page 3]


Internet-Draft                 EAP-TLS 1.3                     July 2017


3.1.  Base Case

   After receiving the peer's Identity (NAI), the EAP server MUST
   respond with an EAP-TLS/Start packet.  This is an EAP-Request packet
   with EAP-Type=EAP-TLS, the Start (S) bit set, and no data.  The EAP-
   TLS conversation will then begin.  The EAP-TLS conversation consists
   of EAP-Response and EAP-Request packets with EAP-Type=EAP-TLS and
   with the data field encapsulating one or more TLS records in TLS
   record layer format.  The formating and processing of the TLS
   handshake SHALL be done as specified by TLS 1.3 [I-D.ietf-tls-tls13].
   This document only lists additional requirements, restrictions, and
   processing compared to TLS 1.3.

   The peer responds to the EAP-Request with EAP-Response packet with
   EAP-Type=EAP-TLS.  The data field in the response encapsulates one or
   more TLS records in TLS record layer format, containing a TLS
   ClientHello handshake message.  The ClientHello message contains the
   peer's legacy_version that MUST be set to 0x0303, a random number, a
   legacy_session_id that MUST be set as a zero length vector (i.e., a
   single zero byte length field), a set of ciphersuites supported by
   the peer, a legacy_compression_methods vector field that MUST contain
   exactly one byte set to zero.  The ClientHello must include the
   supported_versions extension.  Peers can request additional
   functionality using extensions in the ClientHello message.

   After receiving the EAP-Response containing the ClientHello, the EAP-
   Server sends an EAP-Request packet with EAP-Type=EAP-TLS.  The data
   field of this packet contains one or more TLS records for TLS
   ServerHello, Encrypted extensions, a CertificateRequest, the server
   Certificate along with an explicit proof of the server identity
   (CertificateVerify), followed by finished handshake message.

   The ServerHello contains the version of TLS.  EAP Servers MUST select
   a version from the list in ClientHello's supported_versions
   extension.  For this version of the specification, the version is
   0x0304.  The ServerHello also contains a random number, a single
   cipher_suites selected by the server from the list in the
   ClientHello, and the "key_share" extension which specifies the
   cryptographic parameters such as the named group for the key being
   exchanged.

   After receiving the EAP-Response containing the ServerHello, the EAP-
   Server sends an EAP-Request packet with EAP-Type=EAP-TLS.  The data
   field of this packet contains one or more TLS records for TLS
   Certificate, CertificateVerify, followed by finished handshake
   message.





Mattsson & Sethi         Expires January 4, 2018                [Page 4]


Internet-Draft                 EAP-TLS 1.3                     July 2017


   After the TLS handshake has completed, the EAP server sends EAP
   Success.  In the case where the EAP-TLS with mutual authentication is
   successful, the conversation will appear as shown in Figure 1.


    EAP Peer                                              EAP Server

                                                         EAP-Request/
                               <--------                    Identity
    EAP-Response/
    Identity (MyID)            -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                               <--------                  (TLS Start)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS ClientHello)           -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                                                    (TLS ServerHello,
                                             TLS EncryptedExtensions,
                                              TLS CertificateRequest,
                                                     TLS Certificate,
                                               TLS CertificateVerify,
                               <--------                TLS Finished)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS Certificate,
    TLS CertificateVerify,
    TLS Finished)              -------->
                               <--------                 EAP-Success


            Figure 1: EAP-TLS base case - Mutual authentication

   While the EAP server SHOULD require peer authentication, this is not
   mandatory, since there are circumstances in which peer authentication
   will not be needed (e.g., emergency services, as described in
   [RFC7406]), or where the peer will authenticate via some other means.

   If the EAP Server does not desire the peer to authenticate itself,
   the CertificateRequest is omitted, and the EAP Peer therefore does
   not send Certificate and CertificateVerify.  The message flow is
   shown in Figure 2.







Mattsson & Sethi         Expires January 4, 2018                [Page 5]


Internet-Draft                 EAP-TLS 1.3                     July 2017


    EAP Peer                                              EAP Server

                                                         EAP-Request/
                               <--------                    Identity
    EAP-Response/
    Identity (MyID)            -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                               <--------                  (TLS Start)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS ClientHello)           -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                                                    (TLS ServerHello,
                                             TLS EncryptedExtensions,
                                                     TLS Certificate,
                                               TLS CertificateVerify,
                               <--------                TLS Finished)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS Finished)              -------->
                               <--------                 EAP-Success


         Figure 2: EAP-TLS base case - Server authentication only

3.2.  Resumption

   The purpose of resumption is to allow for improved efficiency in the
   case where a peer repeatedly attempts to authenticate to an EAP
   server within a short period of time.

   Once a TLS handshake has completed, the EAP Server can send the EAP
   Peer a PSK identity (TLS NewSessionTicket) that corresponds to a key
   derived from the handshake.  It is left up to the EAP Server whether
   to support resumption.

   An initial authentication, where both sides authenticate successfully
   and the EAP Server sends a TLS NewSessionTicket is shown in Figure 3.











Mattsson & Sethi         Expires January 4, 2018                [Page 6]


Internet-Draft                 EAP-TLS 1.3                     July 2017


    EAP Peer                                              EAP Server

                                                         EAP-Request/
                               <--------                    Identity
    EAP-Response/
    Identity (MyID)            -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                               <--------                  (TLS Start)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS ClientHello)           -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                                                    (TLS ServerHello,
                                             TLS EncryptedExtensions,
                                              TLS CertificateRequest,
                                                     TLS Certificate,
                                               TLS CertificateVerify,
                               <--------                TLS Finished)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS Certificate,
    TLS CertificateVerify,
    TLS Finished)              -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                               <--------       (TLS NewSessionTicket)
    EAP-Response/
    EAP-Type=EAP-TLS           -------->
                               <--------                 EAP-Success


           Figure 3: EAP-TLS resumption - Initial authentication

   The EAP Peer can then use the PSK identity received in TLS
   NewSessionTicket to negotiate use of the PSK in future
   authentications.  If the server accepts it, then the security context
   of the new connection is tied to the original connection and the key
   derived from the initial handshake is used to bootstrap the
   cryptographic state instead of a full handshake.

   It is up to the peer whether to attempt resumption.  Typically, a the
   peer's decision will be made based on the time elapsed since the
   previous authentication attempt to that EAP server.  Based on the the
   time elapsed since the previous full authentication, the EAP server
   will decide whether to allow resumption or require a full
   authentication.



Mattsson & Sethi         Expires January 4, 2018                [Page 7]


Internet-Draft                 EAP-TLS 1.3                     July 2017


   An subsequent authentication using resumption, where both sides
   authenticate successfully is shown in Figure 4..


    EAP Peer                                              EAP Server

                                                         EAP-Request/
                               <--------                    Identity
    EAP-Response/
    Identity (MyID)            -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                               <--------                  (TLS Start)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS ClientHello)           -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                                                    (TLS ServerHello,
                                             TLS EncryptedExtensions,
                               <--------                TLS Finished)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS Finished)              -------->
                               <--------                 EAP-Success


         Figure 4: EAP-TLS resumption - Subsequent authentication

3.3.  Termination

3.4.  Fragmentation

   A single TLS record may be up several thousand octets in length and a
   TLS message may consiste of multiple TLS records.  TLS certificate
   message may of the order of 10s of Megabytes.  The group of EAP-TLS
   messages sent in a single round may thus be larger than the MTU size
   or the maximum Remote Authentication Dail-In User Service (RADIUS)
   packet size of 4096 octets.  As a result, an EAP-TLS implementation
   MUST provide its own support for fragmentation and reassembly.

   In order to protect against reassembly lockup and denial-of-service
   attacks, it may be desirable for an implementation to set a maximum
   size for one such group of TLS messages.  Since a single certificate
   is rarely longer than a few thousand octets, and no other field is
   likely to be anywhere near as long, a reasonable choice of maximum
   acceptable message length might be 64 Kilobyte as suggested in
   [RFC5216]



Mattsson & Sethi         Expires January 4, 2018                [Page 8]


Internet-Draft                 EAP-TLS 1.3                     July 2017


   This specification reuses the mechanism of fragmentation and
   reassembly specified in [RFC5216].  The fragmentation support is
   provided through addition of a flags octet within the EAP-Response
   and EAP-Request packets, as well as a TLS Message Length field of
   four octets.  The three 1-bit flags included are:

   o  Length included (L) bit flag: is set to indicate the presence of
      the four-octet TLS Message Length field.  It MUST be set for the
      first fragment of a fragmented TLS message or set of messages.

   o  More fragments (M) bit flag: The M flag is set on all but the last
      fragment.

   o  EAP-TLS Start (S) bit flag: The S flag is set only within the EAP-
      TLS start message sent from the EAP server to the peer.

   The remaining 5 bits in the flags octet are reserved.  The TLS
   Message Length field is four octets, and provides the total length of
   the TLS message or set of messages that is being fragmented.  This
   simplifies buffer allocation.

   When an EAP-TLS peer receives an EAP-Request packet with the M bit
   set, it MUST respond with an EAP-Response with EAP-Type=EAP-TLS and
   no data.  This serves as an acknowledgment for the fragment.  The EAP
   server MUST wait until it receives the EAP-Response (acknowledging
   the previous fragment) before sending another fragment.

   As specified in [RFC3748] each EAP packet has an Identifier field.
   The EAP server MUST increment the Identifier field for each fragment
   contained within an EAP-Request, and the peer MUST include this
   Identifier value in the EAP-Response that acknowledges the fragment.

   Similarly, when the EAP Peer needs to fragment a large message, it
   sends an EAP-Response with the M bit set.  The EAP Server MUST
   respond to this with an EAP-Request with EAP-Type=EAP-TLS and no
   data.  This acts as an acknowledgment for the fragment received from
   the EAP peer.  The EAP peer MUST wait until it receives the EAP-
   Request before sending another fragment.  Even when the EAP Peer
   fragments messages over several EAP-Response messages, it is the EAP
   Server that MUST increment the Identifier value for each fragment
   acknowledgment in the EAP-Request, and the peer MUST include this
   Identifier value in the subsequent fragment within the EAP-Response.

3.5.  Key Heirarchy

   ...





Mattsson & Sethi         Expires January 4, 2018                [Page 9]


Internet-Draft                 EAP-TLS 1.3                     July 2017


3.6.  Ciphersuite and Compression Negotiation

   EAP-TLS implementations MUST support TLS v1.3.

   To ensure interoperability, EAP-TLS peers and servers MUST support
   the TLS mandatory-to-implement ciphersuite: TLS_AES_128_GCM_SHA256
   [GCM] and SHOULD implement the TLS_AES_256_GCM_SHA384 [GCM] and
   TLS_CHACHA20_POLY1305_SHA256 [RFC7539] cipher suites.

   During the EAP-TLS conversation the EAP peer and server MUST NOT
   request or negotiate compression.

4.  Security Considerations

4.1.  EAP security claims

   EAP security claims are defined in section 7.2.1 of [RFC3748].  The
   security claims for EAP-TLS are listed in Table 1.

































Mattsson & Sethi         Expires January 4, 2018               [Page 10]


Internet-Draft                 EAP-TLS 1.3                     July 2017


          +-----------------------------------+----------------+
          | Security property                 | EAP-TLS claim  |
          +-----------------------------------+----------------+
          | Authentication mechanism          | Certificates   |
          |                                   |                |
          | Protected cryptosuite negotiation | yes            |
          |                                   |                |
          | Mutual authentication             | yes            |
          |                                   |                |
          | Integrity protection              | yes            |
          |                                   |                |
          | Replay protection                 | yes            |
          |                                   |                |
          | Key derivation                    | yes            |
          |                                   |                |
          | Key strength                      | ...            |
          |                                   |                |
          | Dictionary attack protection      | yes            |
          |                                   |                |
          | Fast reconnect                    | yes            |
          |                                   |                |
          | Cryptographic binding             | not applicable |
          |                                   |                |
          | Session independence              | yes            |
          |                                   |                |
          | Fragmentation                     | no             |
          |                                   |                |
          | Channel binding                   | ...            |
          +-----------------------------------+----------------+

                       Table 1: EAP security claims

4.2.  Certificate Validation and Revocation Checks

   In contrast to the EAP-TLS server, the EAP-TLS peer may not have
   Internet connectivity.  Therefore, the EAP-TLS server SHOULD provide
   its entire certificate chain minus the root to facilitate certificate
   validation by the peer.  The EAP-TLS peer SHOULD support validating
   the server certificate using RFC6818 [RFC6818] compliant path
   validation.

   A EAP server MUST NOT request that a EAP Peer present an OCSP
   response with its certificate, i.e., the EAP server MUST NOT send an
   empty "status_request" extension in its CertificateRequest message.







Mattsson & Sethi         Expires January 4, 2018               [Page 11]


Internet-Draft                 EAP-TLS 1.3                     July 2017


5.  IANA considerations

6.  Acknowledgements

7.  References

7.1.  Normative References

   [GCM]      Dworkin, M., "Recommendation for Block Cipher Modes of
              Operation: Galois/Counter Mode (GCM) and GMAC", NIST
              Special Publication 800-38D , November 2007.

   [I-D.ietf-tls-tls13]
              Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", draft-ietf-tls-tls13-20 (work in progress),
              April 2017.

   [IEEE-802.1X]
              Institute of Electrical and Electronics Engineers, "Local
              and Metropolitan Area Networks: Port-Based Network Access
              Control", IEEE Standard 802.1X-2004. , December 2004.

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

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, Ed., "Extensible Authentication Protocol
              (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
              <http://www.rfc-editor.org/info/rfc3748>.

   [RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
              Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
              March 2008, <http://www.rfc-editor.org/info/rfc5216>.

   [RFC6818]  Yee, P., "Updates to the Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January
              2013, <http://www.rfc-editor.org/info/rfc6818>.

   [RFC7539]  Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
              Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
              <http://www.rfc-editor.org/info/rfc7539>.

   [RFC7542]  DeKok, A., "The Network Access Identifier", RFC 7542,
              DOI 10.17487/RFC7542, May 2015,
              <http://www.rfc-editor.org/info/rfc7542>.



Mattsson & Sethi         Expires January 4, 2018               [Page 12]


Internet-Draft                 EAP-TLS 1.3                     July 2017


7.2.  Informative references

   [IEEE-802.11]
              Institute of Electrical and Electronics Engineers, "IEEE
              Standard for Wireless LAN Medium Access Control (MAC) and
              Physical Layer (PHY) Specifications", November 1997.

   [IEEE-802.16e]
              Institute of Electrical and Electronics Engineers, "IEEE
              Standard for Local and Metropolitan Area Networks - Part
              16: Air Interface for Fixed Broadband Wireless Access
              Systems", April 2002.

   [RFC1661]  Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
              STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
              <http://www.rfc-editor.org/info/rfc1661>.

   [RFC4793]  Nystroem, M., "The EAP Protected One-Time Password
              Protocol (EAP-POTP)", RFC 4793, DOI 10.17487/RFC4793,
              February 2007, <http://www.rfc-editor.org/info/rfc4793>.

   [RFC5433]  Clancy, T. and H. Tschofenig, "Extensible Authentication
              Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method",
              RFC 5433, DOI 10.17487/RFC5433, February 2009,
              <http://www.rfc-editor.org/info/rfc5433>.

   [RFC7406]  Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H.,
              and D. Kroeselberg, "Extensions to the Emergency Services
              Architecture for Dealing With Unauthenticated and
              Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406,
              December 2014, <http://www.rfc-editor.org/info/rfc7406>.

Authors' Addresses

   John Mattsson
   Ericsson
   Farogatan 6
   Kista  16480
   Sweden

   Email: john.mattsson@ericsson.com










Mattsson & Sethi         Expires January 4, 2018               [Page 13]


Internet-Draft                 EAP-TLS 1.3                     July 2017


   Mohit Sethi
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: mohit@piuha.net












































Mattsson & Sethi         Expires January 4, 2018               [Page 14]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/