idnits 2.17.1 draft-qi-ipwave-vehicle-security-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 37 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 10 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 10, 2017) is 2597 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 4301' is mentioned on line 141, but not defined == Unused Reference: 'RFC4301' is defined on line 213, but no explicit reference was found in the text == Unused Reference: 'IEEE1609.2' is defined on line 231, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-19 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPwave Working Group Minpeng Qi 3 Internet-Draft China Mobile 4 Intended Status: Informational 5 Expires: September 10, 2017 March 10, 2017 7 Security Problem statement for IP Wireless Access in Vehicular Environments 8 draft-qi-ipwave-vehicle-security-00 10 Abstract 12 This document specifies security problem about IP wireless access in 13 vehicular environment.It also raise requirements for IPwave as 14 guideline for further security solutions design. At last, using typical 15 IPsec/TLS solution in IPwave are evaluated. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright and License Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3 Message Protection Consideration . . . . . . . . . . . . . . . 3 58 4 Identity Protection Consideration . . . . . . . . . . . . . . . 4 59 5 Current solution analysis . . . . . . . . . . . . . . . . . . . 4 60 5.1 IPsec/TLS with Pre-shared key . . . . . . . . . . . . . . . . 4 61 5.2 IPsec/TLS with certificate . . . . . . . . . . . . . . . . . 5 62 6 Security Consideration . . . . . . . . . . . . . . . . . . . . 6 63 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 64 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 6 66 8.2 Informative References . . . . . . . . . . . . . . . . . . . 6 67 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1 Introduction 71 Under IPwave scenario, a vehicle node usually connects other nodes by 72 using an IP address. The other node could be another vehicle, or a 73 server/infrastructure node with IP address. In this case, communication 74 data could be eavesdropped, modified or forged by the attacker as same 75 as attacks happened in other IP connection. Therefore, IPwave 76 communication must be protected. The protection must consider 77 confidentiality and integrity for unicast and multicast. 78 The protection also need to provide authenticity and privacy for 79 IPwave communication. 81 2 Terminology 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [RFC2119]. 87 3 Message Protection Consideration 89 When a vehicle communicates with another vehicle or RSU. An attacker 90 can sniff the communication nearby. If there is no confidential 91 protection. The attacker could get all information. Although vihecles 92 are usually moving, attacker who want to collect information from 93 specific vehicle can drive a car and follow the target. If attacker 94 want to get general information rather than from specific vehicle, he 95 can sniff nearby an RSU. As a result, information from all vehicles 96 passing by are leaked. So confidentiality should be considered if 97 vehicle wants to send information to a specific target through unicast, 98 or to a specific range targets through multicast. 99 In another hand, an attacker could send out fake message or modified 100 message received from other vehicles/RSUs. So integrity should also be 101 considered. 103 4 Identity Protection Consideration 105 Privacy is critical for IPwave. Since vehicles are outside, an attacker 106 can get vehicle's ID and its physical location. By binding ID and location 107 together, attacker can get more privacy information about the vehicle. For 108 example, track of vehicle could be leaked with its movements. What is more, 109 driver's behavior could be determined. It is a severe violation to the 110 vehicle privacy. 112 Binding on ID and location could be made through two ways. One way is 113 catching vehicle identity based on specific location(s). Here is an 114 example. Attacker set monitor somewhere, he can bind one vehicle's ID 115 and location together when there is only such vehicle there. Another way 116 is catching vehicle location information based on its identity. For 117 example, an attacker could collect one vehicle's GPS information based 118 on its IP address to get the track. 119 As the location is very important to be used for vehicle related service. 120 It is harder to hide location in communication, esp. for nearfield 121 sniffing. So the best way to keep privacy is disconnecting the relation 122 between identity and location. That request identity hidden or updating 123 frequently. 124 However, vehicle's id could not be hidden completely. If vehicle could not 125 be identified by anyone. It can only receive messages but not sending 126 anything out. Vehicles can't use the anonymous way to communicate with the 127 peer. Otherwise, the attacker can also use anonymous way to initiate 128 active attacks, such as sending false messages, etc. 130 So there is only one way left: changing vehicle's identity frequently. 131 However, there are several kinds of attributes which could be used to 132 identify vehicle, such as hardware MAC address, vehicle's IP address, 133 common name in vehicle's certificates, etc. All these attributes should 134 be changed, and should be changed syncronized. If not, a new IP address 135 could be connected to a common name which the certificate is not updated. 136 Then attacker is able to trace the vehicle through its new IP address. 138 5 Current solution analysis 140 There are solutions which could provide data confidentiality and integrity 141 protection with authentication. They are IPsec[RFC 4301] in IP layer and 142 TLS[I-D.ietf-tls-tls13] in transport layer. pre-shared key based and 143 certificate based solutions will be discussed separately. 145 5.1 IPsec/TLS with Pre-shared key 147 When a pre-shared key is used in IPsec/TLS tunnel establishment, it 148 implies that there are agreements between nodes in order to configure 149 same key before connection. However, in the case of V2I/V2V, at least 150 one node is vehicular node, which means that it probably has no 151 agreement with the other peer, and result in no pre-shared key could 152 be applied. 154 5.2 IPsec/TLS with certificate 156 When using certificate in IPsec/TLS establishment, each node who need 157 to be authenticated should own a certificate. In IPwave, if the node 158 with certificate is vehicle type, it means that certificate ID could be 159 used to identify such vehicle. 160 In order to avoid such privacy leakage, vehicle node should not use one 161 certificate in a long time. 163 So if certificates are used in IPsec/TLS establishment, the certificates 164 should be updated frequently. The update timer should be carefully 165 designed. 167 If the time is too long, not only certificate ID but also the private key 168 would be leaked. The compromised certificate should be revoked. As a 169 result, revocation solution like OCSP[RFC6960] should be used. If the 170 vehicle node uses OCSP to verify peer's certificate, it needs to 171 communicate with CA. This brings additional communication round-trip 172 and disadvantage for high-speed vehicle connection. 174 If the time is too short, for example 5 minutes, it also brings problem. 175 CA should update certificate frequently under such assumption. It is 176 almost equivalent to keep connection between vehicle node and CA, which 177 will raise burdens to the node and CA. It can't be implemented. 178 Furthermore, when vehicle node travels in some areas with no Internet 179 connection, the vehicle node cannot update its certificate in time, 180 which leads to the certificate expiration. A possible solution is 181 letting CA issue certificates with different expiration time to 182 vehicle node. However, CA needs to issue a large number of certificates 183 one-time, as well as vehicle node needs to store a large number of 184 certificates also. For example, if CA needs to issue certificates for 185 one year and let them expired in every 5 minutes, the number will be 186 increased more than 100,000. And vehicle node need to store more than 187 100,000 certificate also. It is not acceptable for real system. Another 188 problem is, such certificates should be used one-by-one strictly, or it 189 would lead unavailable usage for a part of certificates. What is more, 190 although the expiration time between certificates is short, expiration 191 time of some certificates could be long, like the certificate with 192 longest validity time is 1 year rather than 5 minutes. It also faces 193 leakage problem. 195 In a word, using traditional certificate for IPsec/TLS in IPwave has 196 some problems. Some mechanism about certificate similar with IEEE 197 1609.2 should be involved. 199 6 Security Consideration 201 This documents are specifies security issues. 203 7 Acknowledgements 205 8 References 206 8.1 Normative References 208 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 209 Requirement Levels", BCP 14, RFC 2119, 210 DOI 10.17487/RFC2119, March 1997, 211 . 213 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 214 Internet Protocol", RFC 4301, 215 DOI 10.17487/RFC4301, December 2005, 216 . 218 [I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security 219 (TLS) Protocol Version 1.3", 220 draft-ietf-tls-tls13-19(work in progress), 221 March, 2017 223 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 224 Galperin, S., and C. Adams, "X.509 Internet Public Key 225 Infrastructure Online Certificate Status Protocol - OCSP", 226 RFC 6960, DOI 10.17487/RFC6960, June 2013, 227 . 229 8.2 Informative References 231 [IEEE1609.2] "1609.2-2016 - IEEE Standard for Wireless Access in 232 Vehicular Environments--Security Services for 233 Applications and Management Messages". 235 Author's Addresses 237 Minpeng Qi 238 China Mobile 239 32 Xuanwumenxi Ave,Xicheng District 240 Beijing 100053 241 China 243 Email: loopypuzzle@hotmail.com