idnits 2.17.1
draft-dschinazi-ipsecme-sa-init-privacy-addition-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:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (March 5, 2018) is 2243 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Possible downref: Non-RFC (?) normative reference: ref. 'IKEV2IANA'
** Obsolete normative reference: RFC 8229 (Obsoleted by RFC 9329)
Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 ipsecme D. Schinazi
3 Internet-Draft Apple Inc.
4 Intended status: Standards Track March 5, 2018
5 Expires: September 6, 2018
7 Privacy Addition to the Internet Key Exchange Protocol Version 2 (IKEv2)
8 IKE_SA_INIT Exchange
9 draft-dschinazi-ipsecme-sa-init-privacy-addition-00
11 Abstract
13 The Internet Key Exchange Protocol version 2 (IKEv2) provides strong
14 security and privacy properties to both endpoints once they have
15 authenticated each other. However, before an endpoint has validated
16 the peer's AUTH payload, it could be divulging information to an
17 untrusted host. An example of such information is the Identification
18 payload of the initiator. Another example is the fact that a host is
19 running an IKEv2 responder. This document introduces a new
20 "Initialization Authentication Code" notify payload that can be
21 included in IKE_SA_INIT messages to increase their trustworthiness.
22 This new protection is meant to be used in addition to current IKEv2
23 mechanisms and is not meant to replace the AUTH payload in any way.
25 Status of This Memo
27 This Internet-Draft is submitted in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at https://datatracker.ietf.org/drafts/current/.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 This Internet-Draft will expire on September 6, 2018.
42 Copyright Notice
44 Copyright (c) 2018 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (https://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
57 Table of Contents
59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
62 2. Attack Vectors . . . . . . . . . . . . . . . . . . . . . . . 4
63 2.1. On-Path Attacker Targeting Initiator . . . . . . . . . . 4
64 2.2. Off-Path Attacker Targeting Responder . . . . . . . . . . 4
65 3. Initialization Authentication . . . . . . . . . . . . . . . . 5
66 3.1. Computing Initialization Authentication . . . . . . . . . 5
67 3.2. Initialization Authentication Notify Payload . . . . . . 6
68 3.3. Receiving Initialization Authentication . . . . . . . . . 6
69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
70 4.1. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 7
71 4.2. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 7
72 4.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 8
73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
74 6. Normative References . . . . . . . . . . . . . . . . . . . . 8
75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
77 1. Introduction
79 The Internet Key Exchange Protocol version 2 (IKEv2) [RFC7296]
80 provides strong security and privacy properties to both endpoints
81 once they have authenticated each other. However, before an endpoint
82 has validated the peer's AUTH payload, it could be divulging
83 information to an untrusted host. Examples include:
85 o The Identification payload of the initiator is sent with the
86 initiator's first IKE_AUTH request. This payload can be used to
87 track the owner of the device initiating IKE.
89 o Some IKEv2 servers may wish to hide their very existence to avoid
90 being blacklisted by entities that resent the privacy properties
91 an IKEv2/IPsec tunnel can provide to users. If the IKEv2 server
92 is accessible over TLS on a TCP port [RFC8229] that is shared with
93 another protocol, responding to the initiator's IKE_SA_INIT can
94 disclose the server's existence.
96 This document introduces a new "Initialization Authentication Code"
97 (IAC) notify payload that can be included in IKE_SA_INIT messages to
98 increase their trustworthiness. This new protection is meant to be
99 used in addition to current IKEv2 mechanisms and is not meant to
100 replace the AUTH payload in any way.
102 1.1. Requirements Language
104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
106 "OPTIONAL" in this document are to be interpreted as described in
107 [RFC2119] [RFC8174] when, and only when, they appear in all capitals,
108 as shown here.
110 1.2. Terminology
112 This document uses the following terms:
114 Endpoint One of the two hosts that are involved in an IKE exchange.
116 Initiator The endpoint that sends the first IKE_SA_INIT request of
117 the IKE exchange being discussed.
119 Responder The endpoint that is not the initiator.
121 Peer When discussing an endpoint, its peer is the other endpoint
122 participating in the IKE exchange.
124 IASS Initialization Authentication Shared Secret, a shared
125 secret included in the IKEv2 configuration. It is separate
126 from any shared secret used for computation of the AUTH
127 payload.
129 MAC Message Authentication Code, a cryptographic means of
130 ensuring integrity and authenticity of a message.
132 IAC Initialization Authentication Code, a MAC of IKE_SA_INIT
133 nonces with the IASS.
135 PRF Pseudo-Random Function, a function used to compute the IAC.
137 2. Attack Vectors
139 This document only attempts to address the following attack vectors.
141 2.1. On-Path Attacker Targeting Initiator
143 This attack vector assumes the presence of an active on-path attacker
144 that can block and forge any packets between both endpoints. Without
145 the mechanism described in this document, the attacker can forge an
146 IKE_SA_INIT reply and get the initiator to send it its IKE_AUTH
147 request encrypted with the ephemeral shared secret computed between
148 the initiator and the attacker. This leaks the identity of the
149 initiator (IDi) and can leak the identity of the responder (IDr) if
150 the initiator also sent it.
152 2.2. Off-Path Attacker Targeting Responder
154 Some network middleboxes may wish block to block IKEv2 negotiation.
155 This is often done by blocking UDP traffic which can be worked around
156 using IKEv2 TCP encapsulation [RFC8229]. This obfuscation can even
157 be improved by encapsulating IKEv2 and IPsec inside TLS. However, a
158 more persevering middlebox can establish a TLS connection to the
159 responder and try to send an IKE_SA_INIT to probe the server for
160 IKEv2 support. Without the mechanism described in this document, the
161 responder has to send an IKE_SA_INIT reply before it's established
162 any initiator identity, leaking the presence of the IKEv2 server.
164 3. Initialization Authentication
166 3.1. Computing Initialization Authentication
168 Each endpoint configuration will include both an IASS and a PRF for
169 this endpoint, and also IASS and PRF of the peer. It will commonly
170 be the case (but it is not required) that the same IASS and the same
171 PRF is used in both directions.
173 The peers authenticate the IKE_SA_INIT messages by having each MAC
174 nonces using a padded shared secret as the key. The IAC is computed
175 as follows:
177 IAC_i = prf_i( prf_i(IASS_i, "Initialization Authentication Key Pad
178 for IKEv2 Initiator"), Ni)
180 IAC_r = prf_r( prf_r(IASS_r, "Initialization Authentication Key Pad
181 for IKEv2 Responder"), Ni | Nr)
183 Where IAC_i and IAC_r are the Initialization Authentication Codes of
184 the initiator and responder respectively. Ni and Nr are the nonces
185 sent in the IKE_SA_INIT messages that contain the IAC. The strings
186 are 57 ASCII characters without null termination. prf_i() and prf_r()
187 denote the PRFs selected in the initiator and responder
188 configurations respectively. IASS_i and IASS_r denote the
189 initialization authentication shared secret in the initiator and
190 responder configurations respectively.
192 The pad strings are added so that if the IASS are derived from a
193 password, the IKE implementation need not store the password in
194 cleartext, which could not be used as a password equivalent for
195 protocols other than IKEv2. Using different pad strings for each
196 direction limits the information leakage about the IASS if IASS_i and
197 IASS_r are equal. IAC_r is based on both Ni and Nr to prevent replay
198 attacks on the IKE_SA_INIT reply while also preventing a MAC oracle
199 on the responder, since the responder controls the random generation
200 of Nr.
202 3.2. Initialization Authentication Notify Payload
204 The Initialization Authentication Notify Payload is defined as
205 follows:
207 1 2 3
208 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
210 | Next Payload |C| RESERVED | Payload Length |
211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
212 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type (=TBD) |
213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
214 | |
215 ~ Initialization Authentication Code ~
216 | |
217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
219 The 'Next Payload', 'C', 'RESERVED', 'Payload Length', 'Protocol ID',
220 'SPI Size', and 'Notify Message Type' fields are the same as
221 described in Section 3 of [RFC7296]. The Critical ('C') bit MUST be
222 set to 0. The 'SPI Size' field MUST be set to 0 to indicate that the
223 SPI is not present in this message. The 'Protocol ID' MUST be set to
224 0, since the notification is specific to this IKE_SA_INIT message.
225 The 'Payload Length' field is set to the length in octets of the
226 entire payload, including the generic payload header. The 'Notify
227 Message Type' field is set to indicate
228 INITIALIZATION_AUTHENTICATION_CODE (TBD). The Initialization
229 Authentication Code field has a variable length, and is computed
230 according to Section 3.1.
232 3.3. Receiving Initialization Authentication
234 When the responder receives the initiator's IKE_SA_INIT request, it
235 has not yet established the identity of the initiator, as the
236 identity payload will come later. If the responder has distributed
237 the same initialization authentication shared secret for all of its
238 clients, it can easily verify that incoming IKE_SA_INIT requests come
239 from clients that possess the shared secret. If the responder uses
240 different initialization authentication shared secrets per client, it
241 will have to iterate all of them to find a match since there is no
242 identity sent with the IKE_SA_INIT request. Care should be taken
243 with regards to the timing of the IKE_SA_INIT reply to avoid leaking
244 information. If the responder cannot find a (IASS, PRF) combination
245 in its configuration that matches the IAC in the incoming IKE_SA_INIT
246 request, it MUST silently ignore the incoming packet. Not responding
247 at all is crucial to hiding the fact that the responder is running an
248 IKEv2 server. The responder SHOULD log the failure to facilitate
249 debugging.
251 When the initiator receives the responder's IKE_SA_INIT reply, it
252 knows the identity of the responder it is trying to establish a
253 security association with. It can therefore use the (IASS, PRF) from
254 its configuration to validate the IAC on the reply. If the IAC in
255 the reply does not match what was computed from the configuration,
256 the initiator treats this similarly to receiving and error on the
257 reply and MUST fail the exchange and MUST NOT send the IKE_AUTH
258 message it would have normally sent. This is crucial to protect the
259 initiator identity (IDi) from an active on-path attacker. The
260 initiator SHOULD log the failure to facilitate debugging.
262 4. Security Considerations
264 This document attempts to resolve the attacks described in Section 2
265 and no other attacks on IKEv2.
267 4.1. Timing Attacks
269 An IKEv2 responder wishing to stay hidden needs to ensure it doesn't
270 leak information via the timing of its responses. In general if it
271 receives an IKE_SA_INIT message whose IAC does not match, it simply
272 does not respond. However if IKEv2 is running over TCP, the timing
273 of when the responder closes the TCP connection can leak information.
274 Implementors of hidden IKEv2 responders should ensure that they reply
275 to bad input and to invalid IAC in similar time. In particular, if
276 the server is also running another application protocol on the same
277 port, it SHOULD reply to an invalid or missing IAC the same way as it
278 would reply to an invalid request on that other protocol.
280 4.2. Replay Attacks
282 The initiator's IKE_SA_INIT message is sent unencrypted and can be
283 replayed. The mechanism described in this document is still
284 vulnerable to replays of the IKE_SA_INIT message. Note however that
285 an obfuscated IKEv2 server running over TLS can leverage TLS to
286 ensure the absence of on-path attackers inside the TLS channel
287 between both endpoints.
289 The responder's IKE_SA_INIT message is also sent unencrypted and can
290 also be replayed. However, the Initialization Authentication Code
291 takes Ni as input so replaying a previous responder IKE_SA_INIT for a
292 different IKEv2 exchange will have a different IAC and will be
293 ignored.
295 4.3. Denial of Service Attacks
297 An IKEv2 responder implementing this specification opens themselves
298 to computing more MACs for IKE_SA_INIT messages. We believe that
299 downside is negligible compared to other DOS attacks on IKEv2.
301 5. IANA Considerations
303 If approved, this document defines a new payload in the IANA "IKEv2
304 Notify Message Types - Status Types" registry [IKEV2IANA]:
306 NOTIFY messages: status types Value
307 -----------------------------------------------------------------
308 INITIALIZATION_AUTHENTICATION_CODE TBD
310 6. Normative References
312 [IKEV2IANA]
313 "IANA, Internet Key Exchange Version 2 (IKEv2)
314 Parameters",
315 .
317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
318 Requirement Levels", BCP 14, RFC 2119,
319 DOI 10.17487/RFC2119, March 1997,
320 .
322 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
323 Kivinen, "Internet Key Exchange Protocol Version 2
324 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
325 2014, .
327 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
328 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
329 May 2017, .
331 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
332 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
333 August 2017, .
335 Author's Address
337 David Schinazi
338 Apple Inc.
339 1 Infinite Loop
340 Cupertino, California 95014
341 US
343 Email: dschinazi@apple.com