[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

IPwave Working Group                                          Minpeng Qi
Internet-Draft                                              China Mobile
Intended Status: Informational
Expires: September 10, 2017                                March 10, 2017



  Security Problem statement for IP Wireless Access in Vehicular Environments
                      draft-qi-ipwave-vehicle-security-00


Abstract

   This document specifies security problem about IP wireless access in
   vehicular environment.It also raise requirements for IPwave as
   guideline for further security solutions design. At last, using typical
   IPsec/TLS solution in IPwave are evaluated.


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.

   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 current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice

   Copyright (c) 2014 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


Minpeng Qi               Expires September 10, 2017             [Page 1]


Internet-Draft  Security Problem Statement for IPwave      March 10, 2017


   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 . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3  Message Protection Consideration  . . . . . . . . . . . . . . .  3
   4  Identity Protection Consideration . . . . . . . . . . . . . . .  4
   5  Current solution analysis . . . . . . . . . . . . . . . . . . .  4
   5.1  IPsec/TLS with Pre-shared key . . . . . . . . . . . . . . . .  4
   5.2  IPsec/TLS with certificate  . . . . . . . . . . . . . . . . .  5
   6  Security Consideration  . . . . . . . . . . . . . . . . . . . .  6
   7  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . .  6
   8  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   8.1  Normative References  . . . . . . . . . . . . . . . . . . . .  6
   8.2  Informative References  . . . . . . . . . . . . . . . . . . .  6
   Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . .  7

























Minpeng Qi               Expires September 10, 2017              [Page 2]


Internet-Draft  Security Problem Statement for IPwave       March 10, 2017


1  Introduction

   Under IPwave scenario, a vehicle node usually connects other nodes by
   using an IP address. The other node could be another vehicle, or a
   server/infrastructure node with IP address. In this case, communication
   data could be eavesdropped, modified or forged by the attacker as same
   as attacks happened in other IP connection. Therefore, IPwave
   communication must be protected. The protection must consider
   confidentiality and integrity for unicast and multicast.
   The protection also need to provide authenticity and privacy for
   IPwave communication.



2  Terminology

   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 RFC 2119 [RFC2119].

3  Message Protection Consideration

   When a vehicle communicates with another vehicle or RSU. An attacker
   can sniff the communication nearby. If there is no confidential
   protection. The attacker could get all information. Although vihecles
   are usually moving, attacker who want to collect information from
   specific vehicle can drive a car and follow the target. If attacker
   want to get general information rather than from specific vehicle, he
   can sniff nearby an RSU. As a result, information from all vehicles
   passing by are leaked. So confidentiality should be considered if
   vehicle wants to send information to a specific target through unicast,
   or to a specific range targets through multicast.
   In another hand, an attacker could send out fake message or modified
   message received from other vehicles/RSUs. So integrity should also be
   considered.




Minpeng Qi               Expires September 10, 2017              [Page 3]


Internet-Draft  Security Problem Statement for IPwave       March 10, 2017


4  Identity Protection Consideration

   Privacy is critical for IPwave. Since vehicles are outside, an attacker
   can get vehicle's ID and its physical location. By binding ID and location
   together, attacker can get more privacy information about the vehicle. For
   example, track of vehicle could be leaked with its movements. What is more,
   driver's behavior could be determined. It is a severe violation to the
   vehicle privacy.

   Binding on ID and location could be made through two ways. One way is
   catching vehicle identity based on specific location(s). Here is an
   example. Attacker set monitor somewhere, he can bind one vehicle's ID
   and location together when there is only such vehicle there. Another way
   is catching vehicle location information based on its identity. For
   example, an attacker could collect one vehicle's GPS information based
   on its IP address to get the track.
   As the location is very important to be used for vehicle related service.
   It is harder to hide location in communication, esp. for nearfield
   sniffing. So the best way to keep privacy is disconnecting the relation
   between identity and location. That request identity hidden or updating
   frequently.
   However, vehicle's id could not be hidden completely. If vehicle could not
   be identified by anyone. It can only receive messages but not sending
   anything out. Vehicles can't use the anonymous way to communicate with the
   peer. Otherwise, the attacker can also use anonymous way to initiate
   active attacks, such as sending false messages, etc.

   So there is only one way left: changing vehicle's identity frequently.
   However, there are several kinds of attributes which could be used to
   identify vehicle, such as hardware MAC address, vehicle's IP address,
   common name in vehicle's certificates, etc. All these attributes should
   be changed, and should be changed syncronized. If not, a new IP address
   could be connected to a common name which the certificate is not updated.
   Then attacker is able to trace the vehicle through its new IP address.

5  Current solution analysis

   There are solutions which could provide data confidentiality and integrity
   protection with authentication. They are IPsec[RFC 4301] in IP layer and
   TLS[I-D.ietf-tls-tls13] in transport layer. pre-shared key based and
   certificate based solutions will be discussed separately.

5.1  IPsec/TLS with Pre-shared key

   When a pre-shared key is used in IPsec/TLS tunnel establishment, it
   implies that there are agreements between nodes in order to configure
   same key before connection. However, in the case of V2I/V2V, at least
   one node is vehicular node, which means that it probably has no
   agreement with the other peer, and result in no pre-shared key could
   be applied.

Minpeng Qi               Expires September 10, 2017              [Page 4]


Internet-Draft  Security Problem Statement for IPwave       March 10, 2017


5.2  IPsec/TLS with certificate

   When using certificate in IPsec/TLS establishment, each node who need
   to be authenticated should own a certificate. In IPwave, if the node
   with certificate is vehicle type, it means that certificate ID could be
   used to identify such vehicle.
   In order to avoid such privacy leakage, vehicle node should not use one
   certificate in a long time.

   So if certificates are used in IPsec/TLS establishment, the certificates
   should be updated frequently. The update timer should be carefully
   designed.

   If the time is too long, not only certificate ID but also the private key
   would be leaked. The compromised certificate should be revoked. As a
   result, revocation solution like OCSP[RFC6960] should be used. If the
   vehicle node uses OCSP to verify peer's certificate, it needs to
   communicate with CA. This brings additional communication round-trip
   and disadvantage for high-speed vehicle connection.

   If the time is too short, for example 5 minutes, it also brings problem.
   CA should update certificate frequently under such assumption. It is
   almost equivalent to keep connection between vehicle node and CA, which
   will raise burdens to the node and CA. It can't be implemented.
   Furthermore, when vehicle node travels in some areas with no Internet
   connection, the vehicle node cannot update its certificate in time,
   which leads to the certificate expiration. A possible solution is
   letting CA issue certificates with different expiration time to
   vehicle node. However, CA needs to issue a large number of certificates
   one-time, as well as vehicle node needs to store a large number of
   certificates also. For example, if CA needs to issue certificates for
   one year and let them expired in every 5 minutes, the number will be
   increased more than 100,000. And vehicle node need to store more than
   100,000 certificate also. It is not acceptable for real system. Another
   problem is, such certificates should be used one-by-one strictly, or it
   would lead unavailable usage for a part of certificates. What is more,
   although the expiration time between certificates is short, expiration
   time of some certificates could be long, like the certificate with
   longest validity time is 1 year rather than 5 minutes. It also faces
   leakage problem.

   In a word, using traditional certificate for IPsec/TLS in IPwave has
   some problems. Some mechanism about certificate similar with IEEE
   1609.2 should be involved.







Minpeng Qi               Expires September 10, 2017               [Page 5]


Internet-Draft  Security Problem Statement for IPwave       March 10, 2017


6  Security Consideration

   This documents are specifies security issues.

7  Acknowledgements

8  References
8.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,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301,
                          DOI 10.17487/RFC4301, December 2005,
                          <http://www.rfc-editor.org/info/rfc4301>.

   [I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security
                        (TLS) Protocol Version 1.3",
                                                draft-ietf-tls-tls13-19(work in progress),
                                                March, 2017

   [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
              Galperin, S., and C. Adams, "X.509 Internet Public Key
                          Infrastructure Online Certificate Status Protocol - OCSP",
                          RFC 6960, DOI 10.17487/RFC6960, June 2013,
                          <http://www.rfc-editor.org/info/rfc6960>.


8.2  Informative References

   [IEEE1609.2]   "1609.2-2016 - IEEE Standard for Wireless Access in
                                   Vehicular Environments--Security Services for
                                   Applications and Management Messages". <https://
                                   standards.ieee.org/findstds/standard/1609.2-2016.html>














Minpeng Qi               Expires September 10, 2017               [Page 6]


Internet-Draft  Security Problem Statement for IPwave       March 10, 2017

Author's Addresses

   Minpeng Qi
   China Mobile
   32 Xuanwumenxi Ave,Xicheng District
   Beijing 100053
   China

   Email: loopypuzzle@hotmail.com



Minpeng Qi               Expires September 10, 2017              [Page 7]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/