Internet DRAFT - draft-guan-6man-ipv6-id-authentication
draft-guan-6man-ipv6-id-authentication
6MAN J.F. Guan
Internet-Draft BUPT
Intended status: Informational S. Yao
Expires: 29 August 2024 THU
K.X. Liu
X.L. Hu
J.L. Liu
BUPT
February 2024
Terminal Identity Authentication Based on Address Label
draft-guan-6man-ipv6-id-authentication-00
Abstract
Privacy and accountability are currently significant concerns on the
internet. Privacy generally implies untraceable sources. Effective
verification methods inherently raise privacy concerns when
confirming a user's identity. To prevent extensive modifications to
current network protocols and the introduction of new identifiers, we
propose an IPv6 based address label terminal identity authentication
mechanism. This mechanism facilitates user identity verification,
ensuring privacy protection, security, and efficient auditing.
Additionally, this document outlines the implementation of address
label authentication in the IPv6 extension header.
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 4 August 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Guan, et al. Expires 29 August 2024 [Page 1]
Internet-Draft Terminal Identity Authentication Based o February 2024
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. Address Label Extension Header Format . . . . . . . . . . . . 3
2.1. Extra Encrypted Auth . . . . . . . . . . . . . . . . . . 4
2.2. Integrity Protection Code . . . . . . . . . . . . . . . . 5
3. Address Label Protocol Processing . . . . . . . . . . . . . . 6
3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Network Environment . . . . . . . . . . . . . . . . . . . 6
3.3. Address Label Packet Sending . . . . . . . . . . . . . . 7
3.4. Address Label Packet Forwarding . . . . . . . . . . . . . 7
3.5. Address Label Packet Reception . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4.1. Randomness Requirements . . . . . . . . . . . . . . . . . 8
4.2. Anonymous AddressR . . . . . . . . . . . . . . . . . . . 8
4.3. Unlinkability . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Integrity Protection . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
The identity authentication mechanism, relying on address labels,
utilizes the user's multi-dimensional attributes. It designs a
unified user identity and employs a distributed consensus
infrastructure for consensus and management. The user identity is
anonymized and embedded in the data packet to ensure secure data
transmission. The cross-domain receiving end verifies the
authenticity and trustworthiness of the terminal identity through the
dynamic label authentication mechanism.
The address label identifies the identity of different terminals.
The address label serves as an identifier, created by initializing
the multidimensional attribute table of the terminal and encrypting
it using a symmetric key. The length of the address label depends on
the length of the encryption algorithm. A section of the address
Guan, et al. Expires 29 August 2024 [Page 2]
Internet-Draft Terminal Identity Authentication Based o February 2024
label will be incorporated into the IPv6 address, serving as a
communication identifier. The remaining part will accompany the data
packet to the next hop. At the subsequent hop, the device will
utilize this information to acquire the complete address label.
Given the aforementioned reasons, we employ address label extension
headers to transmit terminal identity for authentication and scrutiny
within the network. We make full use of the IPv6 address space to
establish a robust connection among terminal identity, address, and
data. This allows address labels to withstand diverse attacks like
tampering, replay, and forgery.
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].
2. Address Label Extension Header Format
The ALE extension header is encapsulated in the Hop-by-Hop Options
header. The (outer) protocol header (IPv6, or Extension) that
immediately precedes the ALE header contain the value 0 in its Next
Header field[RFC5871] (see IANA web page at
http://www.iana.org/assignments/protocol-numbers). Figure 1
illustrates the basic format of the ALE header[RFC6564] [RFC7045].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Length | Opt Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EEA Type | IPC Type | Reserve |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Extra Encrypted Address(variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Integrity Protection Code(variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Basic Format of the LAE Header
* The Next Header field identifies the type of header immediately
following the Hop-by-Hop Options header[RFC8200].
Guan, et al. Expires 29 August 2024 [Page 3]
Internet-Draft Terminal Identity Authentication Based o February 2024
* The Length field indicates the length of the Hop-by-Hop Options
header in 8-octet units, not including the first 8 octets.
* The Opt Type field identifies address label data with a value of
0xf3[RFC8200].
* The Opt Data Len field indicates the length of the entire ALE
header in 8 bytes, including the variable length Extra Encrypted
Auth and Identity Protection Code sections.
* The EEA Type field represent the method of encryption used in the
EEA field and the length of it. The value of this field MUST NOT
be 0.
* The IPC Type field represent the method of hash used in the IPC
field and the length of it. The value of this field MUST NOT be
0.
* The Timestamp field represents the timestamp at which the packet
was sent, used to encrypt the symmetric key and generate an
embedded address.
* The Sequence field is usually a serial number bound to the
terminal identity.
* The Extra Encrypted Auth is a variable length field used to store
partially encrypted data with a symmetric key (see Section 2.1).
* The Integrity Protection Code is a variable length field used to
store the hash results of partial terminal identity information
and the entire transport layer data (see Section 2.2).
2.1. Extra Encrypted Auth
The Extra Encrypted Auth field (EEA) represents a partial value
derived from the encryption of identity information using a symmetric
key.
The initial 64 bits of the encryption result will be inserted into
the trailing 64 bits of the IPv6 packet source address (referred to
as the Implicit Identifier IID). The remaining portion will be
stored in the EEA field, ensuring data authenticity and the
inviolability of identity information.
Guan, et al. Expires 29 August 2024 [Page 4]
Internet-Draft Terminal Identity Authentication Based o February 2024
The length of this field MAY vary depending on the selected
encryption algorithm. The data requiring encryption encompasses the
anonymous identity, timestamp, and serial number of the terminal.
The verifier must decrypt these outcomes to authenticate the
identity.
The encryption algorithm type used is represented by the first four
bits of the Encryption Type field, and specific values refer to
Table 1:
+================+======================+=================+
| EEA Type field | Encryption Algorithm | EEA Length/bits |
+================+======================+=================+
| 0 | Reserve | |
+----------------+----------------------+-----------------+
| 1 | SM4 | 64 |
+----------------+----------------------+-----------------+
| 2 | AES128 | 64 |
+----------------+----------------------+-----------------+
| 3 | AES256 | 192 |
+----------------+----------------------+-----------------+
| 4 | DES | 64 |
+----------------+----------------------+-----------------+
| 5 | 3DES | 64 |
+----------------+----------------------+-----------------+
Table 1: Category of Symmetric Key Encryption Algorithm
Values not listed in the table are considered reserved values.
2.2. Integrity Protection Code
The Identity Protection Code field (IPC) is a hash result containing
partial identity information of the terminal and the complete
transport layer data.
The IPC field guarantees data integrity during transmission. The
data subject to hash verification encompasses the IPv6 source
address, destination address, EEA, anonymous terminal identity AID,
timestamp, serial number, and the transport layer data (including
transport layer headers) of the message. In the verification
process, the identical hash operation is applied to these data, and
subsequently, the IPC is compared. Transmission correctness is
confirmed only when the two match; otherwise, this packet should be
discarded.
Guan, et al. Expires 29 August 2024 [Page 5]
Internet-Draft Terminal Identity Authentication Based o February 2024
Different hash algorithms MAY result in different lengths of IPC. We
use the last 4 bits of the Encryption Type field to represent the
current hash algorithm being used, and specific values refer to
Table 2:
+================+======================+=================+
| IPC Type field | Encryption Algorithm | EEA Length/bits |
+================+======================+=================+
| 0 | Reserve | |
+----------------+----------------------+-----------------+
| 1 | SHA256 | 256 |
+----------------+----------------------+-----------------+
| 2 | SHA384 | 384 |
+----------------+----------------------+-----------------+
| 3 | SHA512 | 512 |
+----------------+----------------------+-----------------+
| 4 | MD5 | 128 |
+----------------+----------------------+-----------------+
Table 2: Category of Hash Algorithm
Values not listed in the table are considered reserved values.
3. Address Label Protocol Processing
3.1. Assumptions
The process description for the terminal identity authentication
based on address label will be based on the following assumptions:
(a) All entities can verify the routing prefix generated by AS.
(b) Each host and router in the protocol negotiates a symmetric key
through a secure method for the subsequent protocol service.
The source AS and destination AS also share the corresponding
symmetric key in secret.
(c) The encryption method is assumed to be secure, i.e., encryption
cannot be broken and MACs cannot be forged.
3.2. Network Environment
This document describes a protocol process that includes a Source AS
and a Destination AS, both of which contain a Border Router for
packet forwarding, and each of which contains a User/Host. The
network environment is illustrated in the figure 2 below:
Guan, et al. Expires 29 August 2024 [Page 6]
Internet-Draft Terminal Identity Authentication Based o February 2024
+---------------------+ +---------------------+
| Source AS | | Destination AS |
| | | |
| +--------------+ | | +--------------+ |
| | User/Host | | | | User/Host | |
| | | | | | | |
| +--------------+ | | +--------------+ |
| | | | | |
| | | | | |
| +--------------+ | Internet | +--------------+ |
| | Border | |<--------------->| | Border | |
| | Router | | | | Router | |
| | | | | | | |
| +--------------+ | | +--------------+ |
+---------------------+ +---------------------+
Figure 2: Process Description Topology
3.3. Address Label Packet Sending
Each packet sent from the source host MUST insert the extension
header described above and encrypt the Anonymous Identifier (AID) of
its own IPv6 address using a symmetric key. The first 64 bits of the
encrypted result are used as the IID(implicit Identifier) of the
address, while the remaining bits are used as the EEA in the
extension header. By following these steps, the non-linkability
between the sender and receiver is improved to counter third-party
observers on the same LAN segment and maintain anonymity.
To ensure that there are no errors during data transmission, we also
use IPC fields as a means of verifying data correctness. We use
specific hash algorithms to calculate the checksum of partial
terminal identity information and all transport layer data. In
addition, the original checksum check of the transport layer is also
retained. But due to the modification of the IPv6 address, the
checksum of the transport layer MAY need to be recalculated.
3.4. Address Label Packet Forwarding
For outgoing packets, when the border router of the source AS
receives an outgoing packet, it uses the corresponding symmetric key
to decrypt the IID and EEA of the address, thereby obtaining the
original AID. Next, the border router calculates the IPC using the
IP header and payload and then compares it with the IPC in the packet
to verify the integrity of the packet. If the verification fails,
the border router discards the packet. Otherwise, it uses the
corresponding symmetric key shared with the destination AS to re-
Guan, et al. Expires 29 August 2024 [Page 7]
Internet-Draft Terminal Identity Authentication Based o February 2024
encrypt the AID and forwards the packet.
For incoming packets, when the border router of the destination AS
receives an incoming packet, it requests and reproduces the symmetric
key of the terminal from the domain server based on the information
in the packet extension header, and decrypts the address label to
verify it. If the verification is successful, it encrypts the
original source address's AID using the symmetric key and forwards
the packet.
According to [HBH-OPTIONS-PROCESSING] and [PROC-HBH-OPT-HEADER],
nodes lacking support for the current protocol MAY experience packet
loss.
3.5. Address Label Packet Reception
The packets forwarded by the border router are received by the User/
Host in the destination AS, which decrypts the AID of the source
address with its own symmetric key, and verifies the real source
address of the host with which it communicates. Similarly, the host
needs to verify the correctness of data transmission through IPC
field.
Through the above steps, the protocol in this document can guarantee
that only verified packets can leave the source AS and successfully
reach the destination host.
4. Security Considerations
This section contains security considerations for the protocol
described in this document.
4.1. Randomness Requirements
All random values in the protocol and symmetric key MUST be generated
using a cryptographically secure source of randomness [RFC4086].
4.2. Anonymous AddressR
Attackers can track and identify the sender's activity patterns and
history by using the source address in network traffic to conduct
tracking attacks. In the network environment, the source address is
usually a fixed or stable identifier, such as an IP address, a MAC
address, or other types of identifiers. These identifiers can be
collected and correlated by attackers to construct the sender's
activity patterns and history.
Guan, et al. Expires 29 August 2024 [Page 8]
Internet-Draft Terminal Identity Authentication Based o February 2024
This document protocol ensures that the sender can hide their
identity from the source AS, the transit ASes, the destination AS,
and even the receiver, making it difficult for the source address
information in network traffic to be exposed or identified. This is
because the attacker does not know the symmetric key of the AS, so
they cannot decrypt IDD and EEA to obtain user identifiers and
extract user identities, thus fully protecting the sender's privacy
and security.
However, it is important to note that this document protocol does not
maintain sender anonymity for observers in the LAN segment because
they already know the identity (link layer address) of the sender.
4.3. Unlinkability
Unlinkability in this document refers to the ability of the sender's
different actions or activities to be uncorrelated. This way, the
sender can prevent their actions or activity from being linked by
adversaries or other third parties, thereby avoiding the leakage of
their information or intentions.
Through this protocol, adversaries cannot obtain more information
about the source correlation of traffic by observing any number of
flows from the same Autonomous System (AS). The source correlation
of traffic refers to the possibility of two flows coming from the
same sender. The meaning of traffic here is the same for the sender
and receiver as it is in traditional networks, but it is different
for other devices and observers in the network. This is because the
protocol in this document changes the source or destination address.
In the network environment, adversaries may invade hosts in the same
LAN segment as the sender and obtain clues about the sender's
identity, which leads to a decrease in sender-receiver unlinkability.
When the sender sends a data packet, the invaded host in the LAN
segment can know the source and destination addresses. However, in
this document protocol, since the sender encrypts the AID of the
destination address in each data packet, the invaded host cannot know
the true destination address.
4.4. Integrity Protection
Integrity protection ensures that the information in the extended
header has not been tampered with or modified during packet
transmission.
In this document protocol, if an adversary sends packets with
incorrect IPCs, the border router will concatenate and decrypt the
IID and EEA in the packet and calculate a new IPC using SN,
Guan, et al. Expires 29 August 2024 [Page 9]
Internet-Draft Terminal Identity Authentication Based o February 2024
timestamps, and other data. If the new IPC calculated by the border
router does not match the one in the packet header, the border router
identifies the packet as bogus and discards it. Through the above
analysis, data packets that do not pass the IPC integrity check in
this protocol will not be forwarded, thus ensuring data integrity.
5. IANA Considerations
IANA is asked to assign the Option Type in the "Destination Options
and Hop-by-Hop Options" subregistry of the "Internet Protocol Version
6 (IPv6) Parameters" registry as follows:
+===========+===================+===============+===============+
| Hex Value | Binary Value | Description | Reference |
+===========+=====+=====+=======+===============+===============+
| | act | chg | rest | | |
+===========+=====+=====+=======+===============+===============+
| 0xf3 | 11 | 1 | 10011 | Address Label | This document |
+-----------+-----+-----+-------+---------------+---------------+
Table 3: Destination Options and Hop-by-Hop Options Registry
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC5871] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for
the IPv6 Routing Header", RFC 5871, DOI 10.17487/RFC5871,
May 2010, <https://www.rfc-editor.org/info/rfc5871>.
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, DOI 10.17487/RFC6564, April 2012,
<https://www.rfc-editor.org/info/rfc6564>.
Guan, et al. Expires 29 August 2024 [Page 10]
Internet-Draft Terminal Identity Authentication Based o February 2024
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
6.2. Informative References
[HBH-OPTIONS-PROCESSING]
Hinden, R. and G. Fairhurst, "IPv6 Hop-by-Hop Options
Processing Procedures", Work in Progress, Internet-Draft,
draft-ietf-6man-hbh-processing-04, 21 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
hbh-processing-04>.
[PROC-HBH-OPT-HEADER]
Peng, S., Li, Z., Xie, C., Qin, Z., and G. Mishra,
"Operational Issues with Processing of the Hop-by-Hop
Options Header", Work in Progress, Internet-Draft, draft-
ietf-v6ops-hbh-02, 21 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
hbh-02>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045,
DOI 10.17487/RFC7045, December 2013,
<https://www.rfc-editor.org/info/rfc7045>.
Authors' Addresses
Jianfeng Guan
BUPT
No.10 Xitucheng Road, Haidian District
Beijing
100876
China
Email: jfguan@bupt.edu.cn
Su Yao
THU
No.30 Shuangqing Road, Haidian District
Beijing
100084
China
Email: yaosu@tsinghua.edu.cn
Guan, et al. Expires 29 August 2024 [Page 11]
Internet-Draft Terminal Identity Authentication Based o February 2024
Kexian Liu
BUPT
No.10 Xitucheng Road, Haidian District
Beijing
100876
China
Email: kxliu@bupt.edu.cn
Xiaolong Hu
BUPT
No.10 Xitucheng Road, Haidian District
Beijing
100876
China
Email: hxl814446051@bupt.edu.cn
Jianli Liu
BUPT
No.10 Xitucheng Road, Haidian District
Beijing
100876
China
Email: kuohao233@bupt.edu.cn
Guan, et al. Expires 29 August 2024 [Page 12]
