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]
