Internet DRAFT - draft-qi-its-v2vauth

draft-qi-its-v2vauth



 



IPwave Working Group                                          Minpeng Qi
Internet-Draft                                              China Mobile
Intended Status: Informational
Expires: April 30, 2017                                 October 31, 2016 
                                                            


  Security Problem statement for IP Wireless Access in Vehicular Environments
                      draft-qi-its-v2vauth-01


Abstract

   This document specifies security problem about IP wireless access in 
   vehicular environment. It also analyses the authentication part in 
   IPsec/TLS. It proposes a new solution to make IPsec/TLS more fit for
   vehicular environment.


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 April 30, 2017               [Page 1]

Internet-Draft  Security Problem Statement for IPwave    October 31, 2016


   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
   1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2  IPsec/TLS with Pre-shared key . . . . . . . . . . . . . . . . .  3
   3  IPsec/TLS with certificate  . . . . . . . . . . . . . . . . . .  3
   4  Possible Solution   . . . . . . . . . . . . . . . . . . . . . .  4
   5  Security Consideration  . . . . . . . . . . . . . . . . . . . .  5
   6. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . .  5
   7  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . .  5





   



   

   

   














Minpeng Qi                 Expires April 30, 2017                [Page 2]

Internet-Draft  Security Problem Statement for IPwave     October 31, 2016


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, security channel
   between two nodes like IPsec/TLS are also needed in IPwave to ensure 
   the safety of data transmission. As a result, pre-shared key or 
   certificate are involved when IPsec/TLS tunnel are established.
   However, some issues are raised due to vehicular environment. This 
   document analyzes such issue and will propose security considerations 
   for IPwave.

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

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

3  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. If an attacker could get the physical 
   location of such node, its certificate ID could be used to bind with 
   its location. So the track of vehicle could be obtained with its 
   movements. It is a severe violation to the privacy of vehicle node. 
   In order to avoid such privacy leakage, vehicle node should not use one
   certificate in a long time.

   A simple solution is to make vehicle node anonymous. This could be work 
   when applying TLS between vehicle node as client and infrastructure node
   as a server. However, this could not be work in V2V mode or when vehicle
   need to send out data. Vehicle acts as data sender rather than data 
   receiver. It should guarantee validity of the data it sends 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.

   
Minpeng Qi                 Expires April 30, 2017                [Page 3]

Internet-Draft  Security Problem Statement for IPwave     October 31, 2016


   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 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 certificate for IPsec/TLS in IPwave has some problems.

4. Possible Solution

   Based on the analysis, the problem using pre-shared key is caused by no
   previous agreements before secure tunnel established. And the problem 
   using certificate is caused by the privacy leakage and the validity time.

   So a possible solution is to bind pre-shared key and certificate together.
   By using certificate with insecure environment to generate keys in two 
   nodes, an IPsec/TLS secure tunnel can be established.   





   

Minpeng Qi                 Expires Aprial 30, 2017                [Page 4]

Internet-Draft  Security Problem Statement for IPwave     October 31, 2016


6  Security Consideration

   This documents are specifies security issues.

7  Acknowledgements

8  References


























Author's Addresses

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

   Email: qiminpeng@chinamobile.com



Minpeng Qi                 Expires April 30, 2017                [Page 5]