INTERNET-DRAFT Yaping Liu, Shuo Zhang, Zhiyu Han
Intended Status: Informational Guangzhou university
Expires: July 28, 2023 January 28, 2023
Requirement of Lightweight Authentication and Key Agreement
Protocols for IoT
draft-liu-zhang-han-lakapiot-01
Abstract
This document specifies the requirement of lightweight authentication
and key agreement protocols for Internet of Things (LAKAPIoT).
The authentication and key agreement protocols are very crucial for
IoT since it can prevent unauthorized or malicious IoT devices from
accessing the network. However, most IoT devices have limited storage,
computing and communication capacity. Moreover, the network archi-
tecture of IoT is very different from the traditional network.
Therefore, designing authentication and key agreement protocols for
IoT is an essential step to ensure its security. In this draft, the
requirement of lightweight authentication and key agreement protocols
for IoT is proposed.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. 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." The list of
Internet-Draft Shadow Directories can be accessed at
https://www.ietf.org/shadow.html.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 28, 2023.
Yaping Liu, et al. Expires 28 January 2023 [Page 1]
Internet-Draft Requirement of LAKA Protocols for IoT July 2022
Copyright Notice
Copyright (c) 2022 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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Requirements Language . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . .6
6.1 Normative References . . . . . . . . . . . . . . . . . . .6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
Yaping Liu, et al. Expires 28 January 2023 [Page 2]
Internet-Draft Requirement of LAKA Protocols for IoT July 2022
1 Introduction
Authentication and key agreement protocols are very crucial for IoT
security. Without authentication, these uncertified malicious devices
may cause serious damage to the IoT. However, most IoT devices have
limited storage, computing and communication capacity [RFC8017].
Moreover, the network architecture of IoT is very different from the
traditional network. The complex types of IoT devices and diversity
of communication protocols led to the lack of unified protocols and
standards. Therefore, designing an authentication and key agreement
protocol for IoT is an indispensable step to ensure its security.
With the rapid development of IoT, the security problems have been
increased dramatically. It is important to establish valid authenti-
cation protocols for IoT environments. Authentication and key agree-
ment protocols for IoT face great challenges of balancing between the
security and cost for their constrained resources comparing with
traditional servers and PCs. Recently, some authentication and key
agreement protocols are proposed for constrained environment of IoT
[RFC7228].
Current authentication protocols mainly include two categories:
protocols with lightweight and protocols with high security. The
former one utilizes lightweight operations (such as hash functions
or symmetric key) to design protocols with simple calculations and
verification. The latter one utilizes public key encryption (such as
elliptic curve (ECC) or chaotic map) to provide better security. In
terms of security and computational overhead, both kinds of authenti-
cation protocols are irreconcilable contradictions: 1. the lightweight
scheme is insufficient in terms of security; 2. the public key scheme
can achieve stronger security, but brings larger computational
overhead.
In this draft, we analyze and compare some authentication and key
agreement protocols for IoT, and propose the requirement of
lightweight authentication and key agreement protocols for IoT.
2. Terminology and Requirements Language
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 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying significance described in RFC2119.
Yaping Liu, et al. Expires 28 January 2023 [Page 3]
Internet-Draft Requirement of LAKA Protocols for IoT July 2022
In this document, the characters ">>" preceding an indented line(s)
indicates a statement using the key words listed above. This
convention aids reviewers in quickly identifying or finding the
portions of this RFC covered by these keywords.
3. Motivation
According to the cryptographic primitives, current authentication
protocols for IoT can be divided into four categories: hash and
symmetric key-based, elliptic curve-based, chaotic map-based and
identity-based cryptography (IBC).
(1) Hash and symmetric key-based protocols can greatly reduce the
computing overhead of IoT devices, but they often have poor security.
(2) Elliptic curve-based protocols can guarantee stronger security
properties due to the public key, but elliptic curve scalar
multiplication is more expensive than symmetric cryptography. The IETF
working group proposed the Ephemeral Diffie-Hellman over COSE (EDHOC)
protocol based on the elliptic curve cryptography (ECC) scheme
[draft-ietf-lake-edhoc-15]. However, the scalar multiplication
operation of ECC brings greater challenges to resource-constrained
IoT devices.
(3) Chaotic map-based protocols have lower computational overhead than
elliptic curves and has the security properties of public key schemes.
Chebyshev polynomials can satisfy the principles of confusion and
diffusion in cryptographic design systems, with smaller computational
cost when compared with traditional public key cryptography.
Therefore, the application of chaotic cryptography based on Chebyshev
polynomials has received great attention.
(4) The advantage of IBC protocols is that it reduces the overhead of
querying certificates, but the computational cost of bilinear pairing
operation is relatively large.
The EDHOC protocol and some other protocols for resource-constrained
IoT devices consider the characteristics of computing and insufficient
storage space of terminal devices. They carried out lightweight
optimizations in the process of encryption and decryption. However,
the EDHOC protocol has the following shortcomings in terms of
deployment flexibility and security.
Comparing with traditional symmetric cryptographic schemes, ECC has
higher security and received extensive research and attention. However,
as a public key scheme, it also bears the increase of overhead.
Yaping Liu, et al. Expires 28 January 2023 [Page 4]
Internet-Draft Requirement of LAKA Protocols for IoT July 2022
Since Chebyshev polynomial can have less computational overhead than
the public key cryptography, it can satisfy the diffusion principle
in the cryptographic design while guaranteeing the security properties.
However, current authentication protocols based on Chebyshev
polynomial still have some issues, such as excessive number of chaotic
map operations and the backward security of session keys. Backward
security, also known as future security or post compromise security
(PCS), was formally defined in 2017. It means that even when the
long-term key or session key is leaked or compromised, the security
of messages after the session can still be guaranteed. The scheme of
EDHOC relies on the automatic update of the symmetric session key
after the authentication and key agreement phase are completed.
Therefore, once the session key is leaked, the backward secrecy of
EDHOC cannot be guaranteed.
In summary, although the public key scheme is computationally
expensive, it is more conducive to the design of solutions that can
effectively resist various attacks and implement multiple security
functions. The Chebyshev-based chaotic map has a lower cost than the
traditional public key scheme. Meanwhile, it can preserves security
properties of public key scheme.
It is a feasible way to design an authentication and key agreement
protocol based on Chebyshev chaotic, but it should deal with the
above issues in existing EDHOC and other authentication protocols.
It is better to build on a variant of the SIGMA protocol which
provides identity protection of the initiator (SIGMA-I) against active
attackers, like IKEv2 [RFC7296], TLS [RFC8446] and DTLS [RFC9147].
SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a large
number of variants [SIGMA].
4. IANA Considerations
This document has no actions for IANA.
5. Security Considerations
This document has no actions for Security Considerations.
6 References
6.1 Normative References
[RFC8017] Kathleen Moriarty, Burt Kaliski, Jakob Jonsson,
Andreas Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017,
November 2016, <https://www.rfc-editor.org/info/rfc8017>.
[RFC7228] Carsten Bormann, Mehmet Ersue, Ari Keränen, "Terminology for
Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[RFC7296] Charlie Kaufman, Paul E. Hoffman, Yoav Nir, Pasi Eronen, Tero
Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7296,
Yaping Liu, et al. Expires 28 January 2023 [Page 5]
Internet-Draft Requirement of LAKA Protocols for IoT July 2022
DOI 10.17487/RFC7296, October 2014,
<https://www.rfc-editor.org/info/rfc7296>.
[RFC8446] Eric Rescorla, "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9147] Eric Rescorla, Hannes Tschofenig, Nagendra Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version 1.3",
RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.
[RFC2119] Scott O. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc9147>.
[draft-ietf-lake-edhoc-15] Göran Selander, John Preuß Mattsson,
Francesca Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)",
draft-ietf-lake-edhoc-15, May 2020,
<https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc/>.
Authors' Addresses
Yaping Liu
Guangzhou university
No. 230, West Waihuan Street, Guangzhou city, Guangdong province, China
Email: ypliu@gzhu.edu.cn
Shuo Zhang
Guangzhou university
No. 230, West Waihuan Street, Guangzhou city, Guangdong province, China
Email: 395408397@qq.com
Zhiyu Han
Guangzhou university
No. 230, West Waihuan Street, Guangzhou city, Guangdong province, China
Email: xiaochangzs@126.com
Yaping Liu, et al. Expires 28 January 2023 [Page 6]