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]