idnits 2.17.1 draft-qi-its-v2vauth-01.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 5 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 28 instances of too long lines in the document, the longest one being 5 characters in excess of 72. 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 (October 31, 2016) is 2733 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC2119' on line 84 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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: April 30, 2017 October 31, 2016 7 Security Problem statement for IP Wireless Access in Vehicular Environments 8 draft-qi-its-v2vauth-01 10 Abstract 12 This document specifies security problem about IP wireless access in 13 vehicular environment. It also analyses the authentication part in 14 IPsec/TLS. It proposes a new solution to make IPsec/TLS more fit for 15 vehicular environment. 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 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2 IPsec/TLS with Pre-shared key . . . . . . . . . . . . . . . . . 3 58 3 IPsec/TLS with certificate . . . . . . . . . . . . . . . . . . 3 59 4 Possible Solution . . . . . . . . . . . . . . . . . . . . . . 4 60 5 Security Consideration . . . . . . . . . . . . . . . . . . . . 5 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 62 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1 Introduction 67 Under IPwave scenario, a vehicle node usually connects other nodes by 68 using an IP address. The other node could be another vehicle, or a 69 server/infrastructure node with IP address. In this case, communication 70 data could be eavesdropped, modified or forged by the attacker as same 71 as attacks happened in other IP connection. Therefore, security channel 72 between two nodes like IPsec/TLS are also needed in IPwave to ensure 73 the safety of data transmission. As a result, pre-shared key or 74 certificate are involved when IPsec/TLS tunnel are established. 75 However, some issues are raised due to vehicular environment. This 76 document analyzes such issue and will propose security considerations 77 for IPwave. 79 1.1 Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [RFC2119]. 85 2 IPsec/TLS with Pre-shared key 87 When a pre-shared key is used in IPsec/TLS tunnel establishment, it 88 implies that there are agreements between nodes in order to configure 89 same key before connection. However, in the case of V2I/V2V, at least 90 one node is vehicular node, which means that it probably has no 91 agreement with the other peer, and result in no pre-shared key could 92 be applied. 94 3 IPsec/TLS with certificate 96 When using certificate in IPsec/TLS establishment, each node who need 97 to be authenticated should own a certificate. In IPwave, if the node 98 with certificate is vehicle type, it means that certificate ID could be 99 used to identify such vehicle. If an attacker could get the physical 100 location of such node, its certificate ID could be used to bind with 101 its location. So the track of vehicle could be obtained with its 102 movements. It is a severe violation to the privacy of vehicle node. 103 In order to avoid such privacy leakage, vehicle node should not use one 104 certificate in a long time. 106 A simple solution is to make vehicle node anonymous. This could be work 107 when applying TLS between vehicle node as client and infrastructure node 108 as a server. However, this could not be work in V2V mode or when vehicle 109 need to send out data. Vehicle acts as data sender rather than data 110 receiver. It should guarantee validity of the data it sends out. Vehicles 111 can't use the anonymous way to communicate with the peer. Otherwise, the 112 attacker can also use anonymous way to initiate active attacks, such as 113 sending false messages, etc. 115 So if certificates are used in IPsec/TLS establishment, the certificates 116 should be updated frequently. The update timer should be carefully 117 designed. 119 If the time is too long, not only certificate ID but also the private key 120 would be leaked. The compromised certificate should be revoked. As a 121 result, revocation solution like OCSP should be used. If the vehicle node 122 uses OCSP to verify peer's certificate, it needs to communicate with CA. 123 This brings additional communication round-trip and disadvantage for 124 high-speed vehicle connection. 126 If the time is too short, for example 5 minutes, it also brings problem. 127 CA should update certificate frequently under such assumption. It is 128 almost equivalent to keep connection between vehicle node and CA, which 129 will raise burdens to the node and CA. It can't be implemented. 130 Furthermore, when vehicle node travels in some areas with no Internet 131 connection, the vehicle node cannot update its certificate in time, 132 which leads to the certificate expiration. A possible solution is 133 letting CA issue certificates with different expiration time to 134 vehicle node. However, CA needs to issue a large number of certificates 135 one-time, as well as vehicle node needs to store a large number of 136 certificates also. For example, if CA needs to issue certificates for 137 one year and let them expired in every 5 minutes, the number will be 138 increased more than 100,000. And vehicle node need to store more than 139 100,000 certificate also. It is not acceptable for real system. Another 140 problem is, such certificates should be used one-by-one strictly, or it 141 would lead unavailable usage for a part of certificates. What is more, 142 although the expiration time between certificates is short, expiration 143 time of some certificates could be long, like the certificate with 144 longest validity time is 1 year rather than 5 minutes. It also faces 145 leakage problem. 147 In a word, using certificate for IPsec/TLS in IPwave has some problems. 149 4. Possible Solution 151 Based on the analysis, the problem using pre-shared key is caused by no 152 previous agreements before secure tunnel established. And the problem 153 using certificate is caused by the privacy leakage and the validity time. 155 So a possible solution is to bind pre-shared key and certificate together. 156 By using certificate with insecure environment to generate keys in two 157 nodes, an IPsec/TLS secure tunnel can be established. 159 6 Security Consideration 161 This documents are specifies security issues. 163 7 Acknowledgements 165 8 References 167 Author's Addresses 169 Minpeng Qi 170 China Mobile 171 32 Xuanwumenxi Ave,Xicheng District 172 Beijing 100053 173 China 175 Email: qiminpeng@chinamobile.com