EMU M. Chen, Ed.
Internet-Draft Li. Su
Intended status: Standards Track China Mobile
Expires: 8 January 2023 H.W. Wang
Huawei International Pte. Ltd.
7 July 2022
Use Identity as Raw Public Key in EAP-TLS
draft-chen-emu-eap-tls-ibs-04
Abstract
This document specifies the use of identity as a raw public key in
EAP-TLS, EAP-TLS for TLS1.2 is defined in RFC 5216 and EAP-TLS for
TLS1.3 is defined in the draft draft-ietf-emu-eap-tls13 and draft-
ietf-tls-dtls13. The procedures of EAP-TIBS will consistent with
EAP-TLS's interactive process, Identity-based signature will be
extended to support EAP-TLS's signature algorithms.
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 8 January 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Chen, et al. Expires 8 January 2023 [Page 1]
Internet-Draft EAP TLS IBS July 2022
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use case of the EAP-TIBS . . . . . . . . . . . . . . . . . . 4
4. Structure of the Raw Public Key Extension . . . . . . . . . . 5
5. EAP-TLS using raw public keys . . . . . . . . . . . . . . . . 6
5.1. EAP TLS1.2 Client and Server Handshake Behavior . . . . . 6
5.1.1. raw public keys TLS exchange . . . . . . . . . . . . 6
5.1.2. raw public keys EAP-TLS exchange . . . . . . . . . . 7
5.1.3. EAP-TIBS example . . . . . . . . . . . . . . . . . . 9
5.2. EAP TLS1.3 Client and Server Handshake Behavior . . . . . 11
5.2.1. TLS1.3 handshake . . . . . . . . . . . . . . . . . . 11
5.2.2. EAP-TLS1.3 handshake procedure . . . . . . . . . . . 11
5.2.3. raw public keys EAP-TLS1.3 exchange . . . . . . . . . 12
5.2.4. EAP-TIBS1.3 example . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative references . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
The Extensible Authentication Protocol(EAP) defined in RFC
3748[RFC3748] can provide support for multiple authentication
methods. Transport Layer Security(TLS) provides for mutual
authentication, integrity-protected ciphersuite negotiation, and
exchange between two endpoints. The EAP-TLS defined in RFC 5216
[RFC5216] which combines EAP and TLS that apply EAP method to load
TLS procedures.
Traditionally, TLS client and server public keys are obtained in PKIX
containers in-band as part of the TLS handshake procedure and are
validated using trust anchors based on a PKIX certification authority
(CA). But there is another method, Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Layer Security
Chen, et al. Expires 8 January 2023 [Page 2]
Internet-Draft EAP TLS IBS July 2022
(DTLS) are defined in RFC 7250[RFC7250], the document defines two TLS
extensions client_certificate_type and server_certificate_type, which
can be used as part of an extended TLS handshake when raw public keys
are used. In the draft draft-ietf-emu-eap-tls13 reads certificates
can be of any type supported by TLS including raw public keys. In
RFC7250[RFC7250] it assuming that an out-of-band mechanism is used to
bind the public key to the entity presenting the key.
Digital signatures provide the functions of Sender reliability and
Message integrity. A chain of trust for such signatures is usually
provided by certificates, but in low-bandwidth and resource-
constrained environments, the use of certificates might be
undesirable. In comparison with the original certificate, the raw
public key is fairly small. This document describes a signature
algorithm using identity as a raw public key in EAP-TLS, instead of
transmitting a full certificate in the EAP-TLS message, only public
keys are exchanged between client and server, also known as EAP-TLS-
IBS.
With the existing raw public key scheme, a public key and identity
mapping table is required at server. This table usually established
with offline method and may require additional efforts for
establishment and maintenance, especially when the number of devices
are huge. On the other hand, with IBS signature algorithm, it not
only can take the advantage of raw public key, but also eliminates
the efforts for the mapping table establishment and maintenance at
the server side. Instead, a small table for CRL is enough for
exclude revoked identity from accessing the network. A number of IBE
and IBS algorithms have been standardized, such as ECCSI defined in
RFC 6507[RFC6507].
IBC was first proposed by Adi Shamir in 1984. For an IBC system, a
Key Management System (KMS) is required to generate keys for devices.
The KMS choose its KMS Secret Authentication Key(KSAK) as the root of
trust. A public parameter, KMS Public Authentication Key (KPAK) is
derived from this secrete key and is used by others in verifying the
signature. The signatures are generated by an entity with private
keys obtained from the KMS. KMS is a trusted third party, users or
devices can obtain private key using their identities from KMS. In
IBS the private key is also known as Secret Signing Key(SSK). A
sender can sign a message using SSK. The receiver can verify the
signature with sender's identity and the KPAK.
This document is organized as follows: the second section defines the
terms used in the text; the third section gives a brief overview of
the IBS algorithms; the fourth section presents the example message
flow and message format for EAP-TLS-IBS and follows by security
consideration and IANA cosideration etc.
Chen, et al. Expires 8 January 2023 [Page 3]
Internet-Draft EAP TLS IBS July 2022
2. Terminology
The readers should be familiar with the terms defined in.
In addition, this document makes use of the following terms:
IBC: Identity-Based Cryptograph, it is an asymmetric public key
cryptosystem.
IBS: Identity-based Signature, such as ECCSI.
PKI: Public Key Infrastructure, an infrastructure built with a
public-key mechanism.
authenticator: The entity initiating EAP authentication.
peer: The entity that responds to the authenticator.
backend authenticator server: A backend authentication server is an
entity that provides an authentication service to an
authenticator. When used, this server typically executes EAP
methods for the authenticator.
EAP 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.
3. Use case of the EAP-TIBS
Used for authentication of Internet of Things devices: due to the
limited processing power of IoT devices, resources for secure
identity authentication are limited, especially passive, long life
cycle devices, however, the traditional certificate authentication
based on PKI X509, because of the complexity of certificate
processing and certificate chain authentication, not very suitable
for the Internet of Things scenario. Internet of Things devices
really need a more lightweight authentication method, and EAP-TIBS as
one of the candidates.
Used for systems that do not support CA certificates: an internal
system with network security boundaries that can self-operate the Key
Management System(KMS) secret key distribution center, EAP-TIBS can
be used between internal subsystems.
Chen, et al. Expires 8 January 2023 [Page 4]
Internet-Draft EAP TLS IBS July 2022
4. Structure of the Raw Public Key Extension
To support the negotiation of using raw public between client and
server, a new certificate structure is defined in RFC 7250[RFC7250].
It is used by the client and server in the hello messages to indicate
the types of certificates supported by each side. When RawPublicKey
type is selected for authentication, SubjectPublicKeyInfo which is a
data structure is used to carry the raw public key and its
cryptographic algorithm.
The SubjectPublicKeyInfo structure is defined in Section 4.1 of RFC
5280 [PKIX][RFC5280] and not only contains the raw keys, such as the
public exponent and the modulus of an RSA public key, but also an
algorithm identifier. The algorithm identifier can also include
parameters. The structure of SubjectPublicKeyInfo is shown in
Figure 1:
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }
Figure 1: SubjectPublicKeyInfo ASN.1 Structure
The algorithms identifiers are Object Identifier(OIDs),
AlgorithmIdentifier is also data structure with two fields, OID
represent the cryptographic algorithm used with raw public key, such
as ECCSI, parameters are the necessary parameters associated with the
algorithm.
In the case of IBS algorithm, the User's identity is the raw public
key which can be represented by "subjectPublicKey", when ECCSI is
used as the Identity-based signature algorithm, then "algorithm" is
for ECCSI, and "parameters" is the parameters needed in ECCSI.
So far, IBS has the following four algorithms, the following table is
the corresponding table of Key type and OID.
Chen, et al. Expires 8 January 2023 [Page 5]
Internet-Draft EAP TLS IBS July 2022
+--------------------------+----------------+-----------------------+
| Key Type | Document | OID |
+--------------------------+----------------+-----------------------+
| ISO/IEC 14888-3 IBS-1 | ISO/IEC | 1.0.14888.3.0.7 |
| | 14888-3: IBS-1 | |
| | mechanism | |
+--------------------------+----------------+-----------------------+
| ISO/IEC 14888-3 IBS-2 | ISO/IEC | 1.0.14888.3.0.8 |
| | 14888-3: IBS-2 | |
| | mechanism | |
+--------------------------+----------------+-----------------------+
| ISO/IEC 14888-3 | ISO/IEC | 1.2.156.10197.1.302.1 |
| ChineseIBS(SM9) | 14888-3: | |
| | ChineseIBS | |
| | mechanism | |
+--------------------------+----------------+-----------------------+
| Elliptic Curve-Based | Section 5.2 | 1.3.6.1.5.5.7.6.29 |
| Signatureless For | in RFC 6507 | |
| Identitiy-based | | |
| Encryption (ECCSI) | | |
+--------------------------+----------------+-----------------------+
Table 1: Algorithm Object Identifiers
In the draft draft-wang-tls-raw-public-key-with-ibc, there extend
signature scheme with IBS algorithm which indicated in the client's
"signature_algorithms" extension. The SignatureScheme data structure
also keep pace with the section 4.
5. EAP-TLS using raw public keys
This section describes EAP-TIBS both in the case of TLS1.2 and
TLS1.3, each section contains EAP-TLS and EAP-TLS using raw public
keys full message authentication, and finally give the example when
using IBS.
5.1. EAP TLS1.2 Client and Server Handshake Behavior
5.1.1. raw public keys TLS exchange
As described in [RFC7250][RFC7250], the document intrudoces the use
of raw public keys in TLS/DTLS, the basic raw public key TLS exchange
will appear as follows, Figure 2 shows the client_certificate_type
and server_certificate_type extensions added to the client and server
hello messages. An extension type MUST NOT appear in the ServerHello
unless the same extension type appeared in the corresponding
ClientHello, defined in RFC5246[RFC5246].
Chen, et al. Expires 8 January 2023 [Page 6]
Internet-Draft EAP TLS IBS July 2022
The server_certificate_type extension in the client hello indicates
the types of certificates the client is able to process when provided
by the server in a subsequent certificate payload.
The client_certificate_type and server_certificate_type extensions
sent in the client hello each carry a list of supported certificate
types, sorted by client preference. When the client supports only
one certificate type, it is a list containing a single element. Many
types of certificates can be used, such as RawPublicKey, X.509 and
OpenPGP.
client_hello,
client_certificate_type,
server_certificate_type ->
<- server_hello,
client_certificate_type,
server_certificate_type,
certificate,
server_key_exchange,
certificate_request,
server_hello_done
certificate,
client_key_exchange,
certificate_verify,
change_cipher_spec,
finished ->
<- change_cipher_spec,
finished
Application Data <-------> Application Data
Figure 2: Basic Raw Public Key TLS Exchange
5.1.2. raw public keys EAP-TLS exchange
This section describes EAP-TLS extend using raw public keys, the
procedures is as follows, In the discussion, we will use the term
"EAP server" to denote the ultimate endpoint conversing with the
peer.
Chen, et al. Expires 8 January 2023 [Page 7]
Internet-Draft EAP TLS IBS July 2022
Authenticating 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 client_hello
+signature_algorithm
server_certificate_type,
client_certificate_type)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
{client_certificate_type}
{server_certificate_type}
{TLS certificate}
{TLS server_key_exchange}
{TLS certificate_request}
{TLS server_hello_done}
)
EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
TLS certificate_verify,
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Success
Figure 4: EAP-TLS extend raw public keys authentication procedure with TLS1.2 handshake
Chen, et al. Expires 8 January 2023 [Page 8]
Internet-Draft EAP TLS IBS July 2022
5.1.3. EAP-TIBS example
In this example, both the TLS client and server use ECCSI for
authentication, and they are restricted in that they can only process
ECCSI signature algorithm. As a result, the TLS client sets both the
server_certificate_type and the client_certificate_type extensions to
be raw public key; in addition, the client sets the signature
algorithm in the client hello message to be eccsi_sha256.
Chen, et al. Expires 8 January 2023 [Page 9]
Internet-Draft EAP TLS IBS July 2022
Authenticating 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 client_hello
signature_algorithm = (eccsi_sha256)
server_certificate_type = (RawPublicKey,...)
client_certificate_type = (RawPublicKey,...))->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
{client_certificate_type = RawPublicKey}
{server_certificate_type = RawPublicKey}
{certificate = (1.3.6.1.5.5.7.6.29, hash
value of ECCSIPublicParameters),
serverID)}
{certificate_request = (eccsi_sha256)}
{server_hello_done}
)
EAP-Response/
EAP-Type=EAP-TLS
({certificate = ((1.3.6.1.5.5.7.6.29,
hash value of ECCSIPublicParameters),
ClientID)},
{certificate_verify = (ECCSI-Sig-Value)},
{finished}) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS finished)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Success
Figure 5: EAP-TIBS example
Chen, et al. Expires 8 January 2023 [Page 10]
Internet-Draft EAP TLS IBS July 2022
5.2. EAP TLS1.3 Client and Server Handshake Behavior
TLS1.3 defined in RFC8446, as TLS 1.3 is not directly compatible with
previous versions, all versions of TLS incorporate a versioning
mechanism which allows clients and servers to interoperably negotiate
a common version if one is supported by both peers. when make the
discussion on EAP-TLS using raw public keys we also make a different
with TLS1.2, This section is for EAP-TLS1.3 handshake behavior using
raw public keys and give example for EAP-TLS-IBS.
5.2.1. TLS1.3 handshake
TLS1.3 is more secure than TLS1.2 in preventing eavesdropping,
tampering, and message forgery. The handshake can be thought of
having three phases: Key Exchange, Server Parameters and
Authentication.
5.2.2. EAP-TLS1.3 handshake procedure
EAP-TLS mutual authentication in the case of TLS1.3. defined in the
draft-ietf-emu-eap-tls13. TLS 1.3 provides significantly improved
security, privacy, and reduced latency when compared to earlier
versions of TLS. EAP-TLS with TLS 1.3 further improves security and
privacy by mandating use of privacy and revocation checking.
Chen, et al. Expires 8 January 2023 [Page 11]
Internet-Draft EAP TLS IBS July 2022
EAP Peer EAP Server
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
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 Application Data 0x00
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success
Figure 7: EAP-TLS mutual authentication with TLS1.3 handshake
5.2.3. raw public keys EAP-TLS1.3 exchange
This section describes EAP-TLS1.3 extend using raw public keys, the
procedures is as follows, both client and server have the extension
"key_share", the "key_share" extension contains the endpoint's
cryptographic parameters. the "signature_algorithm" extension
contains the signature algorithm and hash algorithms the client and
server can support for the new signature algorithms specific to the
IBS algorithms. When IBS is chosen as signature algorithm, the
server need to indicated the required IBS signature algorithms int
the signature_algorithm extension within the CertificateRequest.
Chen, et al. Expires 8 January 2023 [Page 12]
Internet-Draft EAP TLS IBS July 2022
Authenticating 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 client_hello
+key_share
+signature_algorithm
server_certificate_type,
client_certificate_type)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
+key_share
{EncryptedExtensions}
{client_certificate_type}
{server_certificate_type}
{certificate}
{CertificateVerify}
{certificateRequest}
{Finished}
)
EAP-Response/
EAP-Type=EAP-TLS
({certificate}
{CertificateVerify}
{Finished}
) ->
EAP-Request/
EAP-Type=EAP-TLS
<--TLS Application Data 0x00
EAP-Response/
EAP-Type=EAP-TLS-->
<- EAP-Success
Figure 8: EAP-TLS1.3 authentication procedure with raw public keys
Chen, et al. Expires 8 January 2023 [Page 13]
Internet-Draft EAP TLS IBS July 2022
5.2.4. EAP-TIBS1.3 example
When the EAP server receives the client hello, it processes the
message. Since it has an ECCSI raw public key from the KMS, it
indicates that it agrees to use ECCSI and provides an ECCSI key by
placing the SubjectPublicKeyInfo structure into the Certificate
payload back to the client, including the OID, the identity of
server, ServerID, which is the public key of server also, and hash
value of KMS public parameters. The client_certificate_type
indicates that the TLS server accepts raw public key. The TLS server
demands client authentication, and therefore includes a
certificate_request, which requires the client to use eccsi_sha256
for signature. A signature value based on the eccsi_sha256 algorithm
is carried in the CertificateVerify. The client, which has an ECCSI
key, returns its ECCSI public key in the Certificate payload to the
server, which includes an OID for the ECCSI signature. The example
of EAP-TLS1.3-IBS is as follows:
Authenticating 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 client_hello
signature_algorithm = (eccsi_sha256)
server_certificate_type = (RawPublicKey)
client_certificate_type = (RawPublicKey))->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
+key_share
{client_certificate_type = RawPublicKey}
{server_certificate_type = RawPublicKey}
{certificate = (1.3.6.1.5.5.7.6.29, hash
value of ECCSIPublicParameters,
serverID)}
{certificate_request = (eccsi_sha256)}
{certificate_verify = {ECCSI-Sig-Value}}
{Finished}
)
Chen, et al. Expires 8 January 2023 [Page 14]
Internet-Draft EAP TLS IBS July 2022
EAP-Response/
EAP-Type=EAP-TLS
({certificate = ((1.3.6.1.5.5.7.6.29,
hash value of ECCSIPublicParameters),
ClientID)},
{certificate_verify = (ECCSI-Sig-Value)},
{Finished})
--->
EAP-Request/
EAP-Type=EAP-TLS
<----TLS Application Data 0x00)
EAP-Response/
EAP-Type=EAP-TLS---->
<---- EAP-Success
Figure 9: EAP-TLS1.3-IBS example
6. Security Considerations
Although the identity authentication has been extended, the
generation of session key still continues the EAP-TLS method.
7. IANA Considerations
This document registers the following item in the "Method Types"
registry under the "extensible Authentication Protocol(EAP) Registry"
heading.
+---------+-------------------+
| Value | Description |
+---------+-------------------+
| TBD | EAP-TIBS |
+---------+-------------------+
8. Acknowledgement
TBD
9. References
9.1. Normative References
[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,
<https://www.rfc-editor.org/info/rfc3748>.
Chen, et al. Expires 8 January 2023 [Page 15]
Internet-Draft EAP TLS IBS July 2022
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
March 2008, <https://www.rfc-editor.org/info/rfc5216>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>.
9.2. Informative references
[RFC6507] Groves, M., "Elliptic Curve-Based Certificateless
Signatures for Identity-Based Encryption (ECCSI)",
RFC 6507, DOI 10.17487/RFC6507, February 2012,
<https://www.rfc-editor.org/info/rfc6507>.
Authors' Addresses
Meiling Chen (editor)
China Mobile
32, Xuanwumen West
BeiJing
BeiJing, 100053
China
Email: chenmeiling@chinamobile.com
Li Su
China Mobile
32, Xuanwumen West
BeiJing
100053
China
Email: suli@chinamobile.com
Chen, et al. Expires 8 January 2023 [Page 16]
Internet-Draft EAP TLS IBS July 2022
Haiguang Wang
Huawei International Pte. Ltd.
11 North Buona Vista Dr, #17-08
SINGAPORE 138589
Singapore
Phone: +65 6825 4200
Email: wang.haiguang1@huawei.com
Chen, et al. Expires 8 January 2023 [Page 17]