Use Identity as Raw Public Key in EAP-TLS
Internet-Draft draft-chen-emu-eap-tls-ibs-04
Meiling Chen, Ed.
China Mobile
32, Xuanwumen West
BeiJing
BeiJing
100053
China
chenmeiling@chinamobile.com
Li Su
China Mobile
32, Xuanwumen West
BeiJing
100053
China
suli@chinamobile.com
Haiguang Wang
Huawei International Pte. Ltd.
11 North Buona Vista Dr, #17-08
Singapore
138589
SG
+65 6825 4200
wang.haiguang1@huawei.com
2022-07-07
Security Area
EMU
Internet-Draft
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.
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 (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.
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.
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.
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.

   +--------------------------+----------------+-----------------------+
   |         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.
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.
EAP TLS1.2 Client and Server Handshake Behavior
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].
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

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.

   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

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.

   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

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.
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.
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.

    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

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.

   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

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}

                    				)
   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

Security Considerations
Although the identity authentication has been extended, the generation of session key still continues the EAP-TLS method.
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          |
              	+---------+-------------------+

Acknowledgement
TBD
References
Normative References
[RFC3748]

Extensible Authentication Protocol (EAP)
B. Aboba
L. Blunk
J. Vollbrecht
J. Carlson
H. Levkowetz, Ed.
June 2004
RFC 3748
DOI 10.17487/RFC3748
[RFC5216]

The EAP-TLS Authentication Protocol
D. Simon
B. Aboba
R. Hurst
March 2008
RFC 5216
DOI 10.17487/RFC5216
[RFC5246]

The Transport Layer Security (TLS) Protocol Version 1.2
T. Dierks
E. Rescorla
August 2008
RFC 5246
DOI 10.17487/RFC5246
[RFC5280]

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
D. Cooper
S. Santesson
S. Farrell
S. Boeyen
R. Housley
W. Polk
May 2008
RFC 5280
DOI 10.17487/RFC5280
[RFC7250]

Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
P. Wouters, Ed.
H. Tschofenig, Ed.
J. Gilmore
S. Weiler
T. Kivinen
June 2014
RFC 7250
DOI 10.17487/RFC7250
Informative references
[RFC6507]

Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI)
M. Groves
February 2012
RFC 6507
DOI 10.17487/RFC6507