-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathdraft-wood-icnrg-securereplica-00.xml
353 lines (269 loc) · 12.9 KB
/
draft-wood-icnrg-securereplica-00.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.28 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="-o*+"?>
<rfc docName="draft-wood-icnrg-securereplica-00" category="std">
<front>
<title abbrev="Secure Replica Service in CCN">Secure Replica Service in CCN</title>
<author initials="M." surname="Mosko" fullname="M. Mosko">
<organization>PARC</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<author initials="C.A." surname="Wood" fullname="Christopher A. Wood">
<organization>PARC</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date year="2016" month="April" day="03"/>
<area>General</area>
<workgroup>icnrg</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>We describe a mechanism for session migration between an authentication endpoint
and content replica in CCN. The technique described herein depends on the CCNx-KE
protocol.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>CCNx-KE is a protocol that enables a consumer and producer to create a session over which
they can communicate securely. Session keys derived from CCNx-KE are used to encrypt
interest and content objects sent between the consumer and producer, as shown below.</t>
<figure><artwork><![CDATA[
+----------+ +----------+
| Consumer <----(encrypted channel)----> Producer |
+----------+ +----------+
]]></artwork></figure>
<t>In many cases, the producer must authenticate the consumer before providing any application
data. Moreover, this producer might not be the one storing the data sought after by
the consumer. Therefore, a mechanism to create a secure session between the consumer
and replica is needed to securely obtain data. One way to do this is for the consumer to
create a session with the replica. However, if consumer authentication is performed, then
the replica is burdened with (a) authenticating the consumer and (b) must possess the private
keys necessary to prove its identity to the consumer. A better solution would be to migrate
a session from a producer (authenticator) to a replica (data distributor) securely.</t>
<t>CCNx-KE <xref target="CCNXKE"/> supports the ability to migrate sessions with a MoveToken. However,
the specification does not describe how to create these tokens. In this document, we describe
how to migrate a CCNx-KE session with a particular MoveToken construction.</t>
</section>
<section anchor="assumptions-and-overview" title="Assumptions and Overview">
<t>If a consumer is to migrate a session from a producer to a replica, then the producer
must necessarily trust the replica service to provide the appropriate content. This
trust is based on economics since the producer is likely to pay the replica for its
services. Under this assumption, we also assume that the producer and replica service
can create a secure session amongst themselves. The producer and replica are assumed to be
able to create and share keys on regular basis. We rely on this assumption in the remainder
of the document.</t>
<t>When a client wishes to obtain data from a replica, the following steps occur:</t>
<t><list style="numbers">
<t>The consumer creates a session with the (authenticating) producer.</t>
<t>The producer redirects the consumer to the best replica (e.g., based on its geographic location).</t>
<t>The producer provides the consumer with a MoveToken to use when migrating to the replica.</t>
</list></t>
<t>This is particular exchange in the context of CCNx-KE is outlined below. We will describe
how MoveChallenge, MovePrefix, MoveProof, and MoveToken are created in the following sections.</t>
<figure><artwork><![CDATA[
Client Producer Replica (MovePrefix)
(Round 2 Interest)
+ MoveChallenge
+------------------------->
(Round 2 Content)
+ MovePrefix, MoveToken
<--------------------------
(Round 3 Interest)
+ MoveToken, MoveProof
+---------------------------------------------------->
(Round 3 Content)
+ NewSessionID
<----------------------------------------------------+
]]></artwork></figure>
</section>
<section anchor="session-migration" title="Session Migration">
<t>Session keys produced by CCNx-KE are derived from the traffic secret constructed
by the consumer and producer. Therefore, to decrypt traffic from the consumer and join
the session, the MoveToken must allow the replica to extract or recover this secret. Moreover,
since this extraction step must involve some computation, the replica must be allowed
to check that the MoveToken was generated by a trusted producer. This is necessary to avoid
trivial computational Denial of Service (DoS) attacks against the replica.</t>
<t>With the requirements in place, we now describe how to generate the MoveChallenge, MoveProof,
and MoveToken.</t>
<section anchor="movechallenge-and-moveproof" title="MoveChallenge and MoveProof">
<t>The MoveChallenge is as defined in <xref target="CCNXKE"/>. It is a random 256-bit string defined as
follows:</t>
<figure><artwork><![CDATA[
MoveChallenge = SHA256(X)
]]></artwork></figure>
<t>for a randomly generated 256-bit string X. The value X is also the MoveProof.</t>
</section>
<section anchor="movetoken" title="MoveToken">
<t>The MoveToken must allow the replica to (a) check that the consumer obtained the MoveToken
from a trusted or known producer and (b) extract the traffic secret (TS) to derive the encryption
and decryption keys. Therefore, it is defined as follows</t>
<figure><artwork><![CDATA[
MoveTokenCT, MoveTokenTag = AEnc(K, MoveChallenge + TS)
MoveToken = K_id + MoveTokenCT + MoveTokenTag
]]></artwork></figure>
<t>where K_id is the key identifier for the key K and + is concatenation. Also, AEnc is
shorthand for authenticated encryption that produces a ciphertext and authentication tag.
One such algorithm is AES-GCM <xref target="GCM"/>.</t>
</section>
<section anchor="verification" title="Verification">
<t>As shown in the protocol diagram above, the consumer must provide both the MoveProof and
MoveToken in the Round 3 Interest (for the desired data). Upon receipt, the replica performs
the following checks:</t>
<t><list style="numbers">
<t>If K_id is not valid, i.e., the replica has no key with that identifier, then
the Interest is dropped.</t>
<t>Otherwise, the replica computes</t>
</list></t>
<figure><artwork><![CDATA[
MoveTokenCT, MoveTokenTag = MoveToken
MoveChallenge + TS = ADec(K, MoveTokenCT, MoveTokenTag)
]]></artwork></figure>
<t>If the decryption fails, i.e., if the encryption is not valid (the ciphertext was tampered with), then
the Interest is dropped.
3. Otherwise, the replica computes</t>
<figure><artwork><![CDATA[
Challenge = SHA256(MoveProof)
]]></artwork></figure>
<t>If Challenge = MoveChallenge, then the replica accepts the Interest. Otherwise, the Interest is dropped.</t>
</section>
<section anchor="final-notes" title="Final Notes">
<t>If the traffic secret is recovered correctly, then the replica creates a new SessionID (NewSessionID) for
the session between the replica and consumer and returns it with the corresponding application data requested
in the Round 3 Interest. At this point, both the consumer and replica have a common SessionID and traffic secret
and can then derive the appropriate encryption keys to use when encrypting traffic.</t>
</section>
<section anchor="replica-workload" title="Replica Workload">
<t>To create a new session, the replica must only perform a single authenticated decryption and hash function (SHA256)
computation. No public-key cryptographic algorithms are required to verify a MoveToken and complete the migration.</t>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>TODO</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor="TLS13" target="https://tools.ietf.org/html/draft-ietf-tls-tls13-11">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author initials="E." surname="Rescorla">
<organization>RTFM, Inc.</organization>
</author>
<date year="2015" month="December" day="28"/>
</front>
</reference>
<reference anchor="DTLS12" target="https://tools.ietf.org/html/rfc6347">
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author initials="E." surname="Rescorla">
<organization>RTFM, Inc.</organization>
</author>
<author initials="N." surname="Modadugu">
<organization>Google, Inc.</organization>
</author>
<date year="2012" month="January"/>
</front>
</reference>
<reference anchor="GCM" >
<front>
<title>Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC</title>
<author initials="M." surname="Dworkin">
<organization></organization>
</author>
<date year="2007" month="November"/>
</front>
<seriesInfo name="NIST" value="Special Publication 800-38D"/>
</reference>
<reference anchor="CCNxMessages" target="https://tools.ietf.org/html/draft-irtf-icnrg-ccnxmessages-01">
<front>
<title>CCNx Messages in TLV Format</title>
<author initials="M." surname="Mosko">
<organization>PARC, Inc.</organization>
</author>
<author initials="I." surname="Solis">
<organization>PARC, Inc.</organization>
</author>
<date year="2016" month="January" day="11"/>
</front>
</reference>
<reference anchor="TLVENCAP" target="https://github.com/PARC/ccnx-tlvencap-rfc">
<front>
<title>CCNx Packet Encapsulation</title>
<author initials="M." surname="Mosko">
<organization>PARC, Inc.</organization>
</author>
<author initials="C." surname="Wood">
<organization>PARC, Inc.</organization>
</author>
<date year="n.d."/>
</front>
</reference>
<reference anchor="CCNXKE" target="TODO">
<front>
<title>CCNx Key Exchange</title>
<author initials="M." surname="Mosko">
<organization>PARC, Inc.</organization>
</author>
<author initials="E." surname="Uzun">
<organization>PARC, Inc.</organization>
</author>
<author initials="C.A." surname="Wood">
<organization>PARC, Inc.</organization>
</author>
<date year="n.d."/>
</front>
</reference>
</references>
<references title='Informative References'>
<reference anchor='RFC5077' target='http://www.rfc-editor.org/info/rfc5077'>
<front>
<title>Transport Layer Security (TLS) Session Resumption without Server-Side State</title>
<author initials='J.' surname='Salowey' fullname='J. Salowey'><organization /></author>
<author initials='H.' surname='Zhou' fullname='H. Zhou'><organization /></author>
<author initials='P.' surname='Eronen' fullname='P. Eronen'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<date year='2008' month='January' />
<abstract><t>This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. This document obsoletes RFC 4507. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5077'/>
<seriesInfo name='DOI' value='10.17487/RFC5077'/>
</reference>
<reference anchor="HASHCHAIN" >
<front>
<title>Password Authentication with Insecure Communication</title>
<author >
<organization>L. Lamport</organization>
</author>
<date year="1981" month="November"/>
</front>
<seriesInfo name="ANSI" value="Communications of the ACM 24.11, pp 770-772"/>
</reference>
</references>
</back>
</rfc>