forked from ksandowi/httpa
-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-sandowicz-httpbis-httpa2-01.xml
1732 lines (1436 loc) · 80.9 KB
/
draft-sandowicz-httpbis-httpa2-01.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
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="utf-8"?>
<rfc category="info" docName="draft-sandowicz-httpbis-httpa2-01"
indexInclude="false" ipr="trust200902" prepTime="2022-10-18T15:31:29Z"
scripts="Common,Latin" sortRefs="true" submissionType="IETF"
symRefs="true" tocDepth="3" tocInclude="true" version="3" xml:lang="en"
xmlns:xi="http://www.w3.org/2001/XInclude">
<front>
<title
abbrev="HTTPA/2">The Hypertext Transfer Protocol Attestable (HTTPA) Version 2</title>
<seriesInfo name="Internet-Draft" stream="IETF"
value="draft-sandowicz-httpbis-httpa2"/>
<author fullname="Shih-han Wang" initials="S." surname="Wang">
<organization>Intel</organization>
<address>
<postal>
<country>US</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Gordon King" initials="G." surname="King">
<organization>Intel</organization>
<address>
<postal>
<country>US</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Nick Li" initials="N." surname="Li">
<organization>Intel</organization>
<address>
<postal>
<country>US</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Ned Smith" initials="N." surname="Smith">
<organization>Intel</organization>
<address>
<postal>
<country>US</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Krzysztof Sandowicz" initials="K." surname="Sandowicz">
<organization>Intel</organization>
<address>
<postal>
<country>PL</country>
</postal>
<phone>+48587661619</phone>
<email>[email protected]</email>
</address>
</author>
<date day="18" month="October" year="2022"/>
<area/>
<workgroup/>
<abstract>
<t/>
<t/>
<t/>
<t>The Hypertext Transfer Protocol Attestable version 2 (HTTPA/2) is an
HTTP extension. It is a transaction-based protocol agnostic to Transport
Layer Security (TLS) in which the Trusted Execution Environment (TEE) is
considered a new type of requested resource over the Internet. The
original Hypertext Transfer Protocol Attestable (HTTPA) (referred to as
HTTPA/1 in the rest of the document) includes remote attestation (RA)
process onto the HTTPS protocol in the assumption of using Transport
Layer Security (TLS) across the Internet. In contrast, the design of
HTTPA/2 could establish a trusted (attested) and more secure
communication without dependence on TLS.</t>
<t>The definition of Attestation for the purposes of this draft:</t>
<t>The process of vouching for the accuracy of TEE based services,
configuration, and data where the TEE conveys Evidence about its
environment, roots of trust and protected functions.
The Evidence is a digital expression of TEE trustworthiness.</t>
<t/>
</abstract>
</front>
<middle>
<section anchor="n-introduction" title="Introduction">
<t/>
<t>The HTTPA/1 <xref target="I-D-11" format="default"/> defines an HTTP extension to handle requests for
remote attestation, secret provisioning, and private data transmission,
so internet visitors can access a wide variety of services running in
Trusted Execution Environments (TEEs) to handle their requests with
strong assurances.</t>
<t>The HTTPA/1 supports mutual attestation if both client and service
endpoints run inside the TEE. Although HTTPA/1 helps build trust between
L7 endpoints with data-level protection, HTTPA/1 needs TLS to defend
against some specific attacks over the Internet, e.g., replay attacks
and downgrade attacks, these attacks are not vulnerable in HTTP/2 due to
specific improvements for them. Note that TLS cannot guarantee
end-to-end security for the HTTPS message exchange <xref target="I-D-1" format="default"/> when the
TEE-based services (TServices) are hosted behind a TLS termination
gateway or inspection appliance (a.k.a. middle boxes). Although the TLS
can provide Confidentiality, Integrity, and Authenticity (ConfIntAuth)
to help ensure the security of message exchange for HTTPA/1 protocol, it
is not a complete end-to-end solution for web services at L7. Both
HTTPA/1 and TLS need to generate key material through key exchange and
derivation processes. This requires additional round trips at L5 and
increases network latency. Thus, there is room to optimize the network
performance further and reduce the communication complexity by avoiding
the repetition of key negotiation. Due to the limitation of TLS
mentioned above, a version of HTTPA with message-level security
protection is a natural candidate to address the issues mentioned above.
This document proposes an upgrade protocol, HTTPA/2, which makes it
possible to secure HTTPA transactions without dependence on TLS. The
HTTPA/2 is designed to improve the processes of key exchange, RA, and
secret provisioning. It also enables end-to-end secure and trustworthy
request/response transactions at L7, which is cryptographically bound to
an attestable service base that can be trusted by internet visitors
regardless of the presence of untrusted TLS termination.</t>
<t>The protocol described in this document focuses on extending the
functionality provided by the HTTPA/1 protocol message formats. This
document alone is sufficient to understand the protocol, and the HTTPA/1
<xref target="I-D-11" format="default"/> could be used as supplemental material.</t>
<t/>
<section anchor="n-conventions-used-in-this-document"
title="Conventions Used in This Document">
<t/>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in [BCP 14], [RFC 2119], [KEYWORDS].</t>
<t/>
<t>In addition to those listed above, this document uses the following
terms:</t>
<t>Trusted Execution Environment (TEE): </t>
<t>TEE is an environment where genuine codes are executed on data with
isolation and memory encryption inaccessible to anyone.</t>
<t/>
<t>Rich Execution Environment (REE): </t>
<t>In contrast to TEE, codes are executed on data without
isolation.</t>
<t/>
<t>Client: </t>
<t>The endpoint initiating the HTTPA connection.</t>
<t/>
<t>Server: </t>
<t>The endpoint did not initiate the HTTPA connection. In HTTPA/2, it
refers to TEE-based Service (TService) running inside an enclave.</t>
<t/>
<t>Client-side verifier(c-verifier):</t>
<t>Verifier from the client side.</t>
<t/>
<t>Server-side verifier(s-verifier):</t>
<t>Verifier from the server side.</t>
<t>Attestation: </t>
<t>Attestation is the process of demonstrating that a software
executable has been properly instantiated on a platform, thus
establishing a level of confidence in the trustworthiness of a remote
peer.</t>
<t/>
<t>Attest Quote(AtQ):</t>
<t>AtQ is an opaque data structure signed by a Quoting Service
(QService) with an attestation key (AK). It can be called a quote or
attestation evidence, which is used to establish trustworthiness
through identities.</t>
<t/>
<t>Attest Base(AtB):</t>
<t>AtB is the totality of computing resources serving client request
handling, including hardware, firmware, software, and access controls
to work together to deliver trustworthy service quality with enforced
security/privacy policy.</t>
<t/>
<t>Attest header line(AHL)</t>
<t>It refers to the different types of header lines used during the
handshake phase, including Attest Ticket, Attest Binder, etc.</t>
<t/>
<t>Attest header Field(AHF)</t>
<t>Regarding the HTTP method, we propose a new HTTP method, called
"ATTEST," to perform the transactions of AtHS and AtSP. The HTTP
request using ATTEST method is called AtR. Regarding HTTP header
fields, we propose to augment them with additional ones called Attest
Header Fields (AHFs) prefixed with the string "Attest-." Without AHFs,
it must be a UtR in terms of HTTPA/2.</t>
<t/>
<t>Attest Ticket(AtT):</t>
<t>AtT is a type of attest header line(AHL) used to ensure the
integrity and authenticity (IntAuth) of AHLs and freshness are
protected cryptographically, except for the AtR of AtHS, the
initiating request for the handshake.</t>
<t/>
<t>Attest Binder (AtBr):</t>
<t>AtBr is a type of AHL used to ensure the binding between the
HTTPA/2 request and the corresponding response.</t>
<t/>
<t>Attest Request (AtR) </t>
<t>Regarding the HTTP method, we propose a new HTTP method, called
"ATTEST," to perform the transactions of Attest Handshake(AtHS) and
Attest Secret Provisioning (AtSP). The HTTP request using ATTEST
method is called AtR. </t>
<t/>
<t>Trusted Computing Base(TCB): </t>
<t>The minimal totality of hardware, software, or firmware must be
trusted for security requirements.</t>
<t/>
<t>Trusted Cargo(TrC):</t>
<t>TrC is a vehicle to carry confidential information which needs to
be protected by authenticated encryption. It can appear in both
HTTPA/2 request and response messages, except for the AtR of AtHS.</t>
<t/>
<t>Trusted Transport Layer Security(TrTLS):</t>
<t>If users want to protect the entire HTTP message?every bit of the
message, HTTPA/2 can leverage TLSto establish a secure connection at
L5 between the client and its adjacent middle box, which we call
TrTLS. </t>
<t>Preflight </t>
<t>This is the first phase of the HTTPA/2 transactions, and it is a
lightweight HTTP OPTIONS request.</t>
</section>
</section>
<section anchor="n-protocol-overview-and-protocol-flow"
title="Protocol Overview and protocol flow">
<t/>
<t>There are three types of requests defined by the HTTPA/2 protocol,
including Un-trusted Request (UtR), Attest Request (AtR), and Trusted
Request (TrR). UtR is used in HTTP(S) transactions; AtR is used in both
transactions of Attest Handshake (AtHS) and Attest Secret Provisioning
(AtSP); TrR is used in the trusted transaction. For convenience, we
refer to the AtR and TrR as "HTTPA/2 request". Regarding the HTTP
method, we propose a new HTTP method, called "ATTEST," to perform the
transactions of AtHS and AtSP. The HTTP request using ATTEST method is
called AtR. Regarding HTTP header fields, we propose to augment them
with additional ones called Attest Header Fields (AHFs) prefixed with
the string "Attest-." Without AHFs, it must be a UtR in terms of
HTTPA/2.</t>
<t>The AHFs are dedicated to HTTPA traffic. For example, they can be
used to authenticate the identity of HTTPA/2 transactions source,
indicate which AtB to request, convey confidential metadata, provision
secrets, present ticket, etc.</t>
<t>The last one is AHL, and it consists of AHF and its values in a
standard form <xref target="RFC8941" format="default"/>. We use it to signify a single piece of
annotated data associated with the current HTTPA/2 request.</t>
<t/>
<section anchor="n-untrusted-request-utr"
title="Untrusted Request (UtR)">
<t/>
<t>An untrusted request is for any transactions that are not
sensitive. The UtR is simply an ordinary type of HTTP request, which
does not use the ATTEST method nor contains any AHLs.</t>
<t>Before a UtR reaches a TService, the UtR can be easily eavesdropped
on or tampered with along the communication path. Even protected by
TLS, it can still be attacked when crossing any application gateway or
L7 firewall since those intervening middle-boxes are untrusted and
will terminate TLS connections hop by hop <xref target="I-D-1" format="default"/>. Therefore, there is no
guarantee of ConfIntAuth. That's why the TService cannot treat the
request as trustworthy, but it is still possible for TService to
handle UtR if allowed by the service-side policy. Thus, we don't
suggest TService to handle any one of them for the sake of
security.</t>
<t/>
</section>
<section anchor="n-attest-request-atr" title="Attest Request (AtR)">
<t/>
<t>The AtR is a HTTP request equipped with both ATTEST method and AHLs
for AtHS and AtSP. If the corresponding TService did not accept any
AtR, subsequent TrR will no longer be valid to this TService. The
major difference between an AtR used in AtHS and AtSP respectively is
as follows:</t>
<t>1)</t>
<t>The AtR used in AtHS is designed to request all necessary resources
for handling both types of AtR used in AtSP and AtHS. For example, one
of the most critical resources is AtB, which may be scheduled or
allocated by a server-side resource arbiter. Typically (but not
always), an upfront TService can directly designate itself as the AtB
for this client.</t>
<t>2)</t>
<t>The AtR of AtSP is optional in HTTPA/2 traffic flow since, in some
cases, the TService does not need any AtB-wide secrets provided by the
client to work. In the typical case, TService needs secret
provisioning to configure its working environment, such as connecting
to databases, setup signing keys and certificates, etc. This AtR must
be issued after all TEE resources have been allocated through the AtHS
transaction described above. It's worth noting that this request is
not required to be issued before any TrR.</t>
<t/>
</section>
<section anchor="n-trusted-request-trr" title="Trusted Request (TrR)">
<t/>
<t>The TrR can be issued right after a successful AtHS where an AtB is
allocated. Although TrR does not use ATTEST method, it should contain
AHLs to indicate that it is a TrR, not a UtR. In other words, the TrR
is nothing but an ordinary HTTP request with some AHLs. Within those
AHLs, one of them must be AtB ID to determine which AtB is targeted in
addition to the specified URI. The TrR can be dispatched to the proper
TService to handle this request.</t>
<t/>
</section>
<section anchor="n-protocol-flow" title="Protocol flow"><t/> <t>As shown
in Figure 1, we illustrate those
transactions from a client perspective, including preflight, AtHS, AtSP,
and trusted requests in a workflow diagram. A detailed explanation of
each phase is in the following chapters. In the design of HTTPA/2, only
the phase of AtHS is required. This largely simplifies the interaction
between the client and the TService and improves the overall service
experience for both security and remote attestation.</t> <t/> <t/>
<figure anchor="ure-figure-1">
<name>HTTPA transaction workflow from the client view</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-----+ +-------------+ no
|START|->|go preflight?|--------------+
+-----+ +-------------+ |
| yes |
v |
+---------+ |
|Preflight| |
+---------+ |
| |
v |
+--------+ no +----+ |
|allowed?|----->|STOP| |
+--------+ +----+ |
yes | |
+---------------------+
|
v
+---------+ yes
|attested?|----------------+
+---------+ |
| no |
v |
+----------------+ |
|Attest Handshake| |
+----------------+ |
| |
+---------------------+
| |
v |
+----+ invalid +------------+ |
|STOP|---------->|Attest base?| |
+----+ +------------+ |
| valid |
v |
+-------------------------+--------------+ |
| | | |
v v v |
+--------------+ +-----------+ +-----------+ |
|need base-wide| no | Trusted | | Untrusted | |
| secrets? |--------+ |Transaction| |Transaction| |
+--------------+ | +-----------+ +-----------+ |
| | | | |
v | | | |
+-------------------+ | | | |
|Secret Provisioning| | | | |
+-------------------+ | | | |
| | | | |
v | | | |
+---------+ no +----+ | | | |
|accepted?|--->|STOP| | | | |
+---------+ +----+ | | | |
| yes | | | |
v v v v |
+-----------------+--------+--------------+ |
| |
v |
+----+ yes +-----------+ no |
|STOP|<--------|terminated?|-----------------------------+
+----+ +-----------+
]]></artwork>
</figure>
<t>The Figure 2 shows the workflow, which can help understand how
those transactions are distinguished in TService.</t> <t/>
<figure anchor="ure-figure-2">
<name>HTTPA transaction workflow from the TService view</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-----+
|START|
+--+--+
|
v
+---------------------------+
| |
v |
yes +------+--------+ no |
+---------+ATTEST request?+--------------+ |
| +---------------+ | |
v | |
contained +-----+-+ not contained | |
+----------+base id+------------+ | |
| +-------+ | | |
v v | |
+-------+-----------+ +--------+-------+ | |
|Secret Provisioning| |Attest Handshake| | |
+------+------------+ +---------+------+ | |
| | | |
v v | |
+-----+---+ invalid +----+ +---+-+ fail +----+ | |
|base-wide+---------->+STOP| |base?+------->+STOP| | |
|secrets? | +----+ +--+--+ +----+ | |
+-----+---+ | | |
| valid | allocated | |
v v | |
++-------------------------------+ | |
| | |
| +----------------------------+ |
| | |
| v |
| contained +---+---+ not contained |
| +---------------+base id+-------------+ |
| | +-------+ | |
| v v |
| +-----+-------------+ yes +---+----+ no |
| |Trusted Transaction| +-----+OPTIONS +----+ |
| +-----+-------------+ | |request?| | |
| | | +--------+ | |
| v v v |
| +-----+-----+ yes +----+ +----+----+ +-------+---+ |
| |terminated?+------>+STOP| |Preflight| | Untrusted | |
| +-----+-----+ +----+ +-----+---+ |Transaction| |
| | | +---------+-+ |
| | v | |
| | no +----+---+ no +----+ | |
| | |allowed?+----->+STOP| | |
| | +----+---+ +----+ | |
| | | yes | |
| | v v |
| | +------------+-------+ |
| | | |
| v v |
| +----------------------------------------+ |
| | |
v v |
+-------------------+---------+ |
| |
v |
+----+ yes +-----+-----+ no |
|STOP+<--------+terminated?+-----------------------------------+
+----+ +-----------+
]]></artwork>
</figure>
</section>
</section>
<section anchor="n-protocol-transactions" title="Protocol Transactions">
<t/>
<section anchor="n-preflight-check-phase" title="Preflight Check Phase">
<t/>
<t>The preflight request uses OPTIONS request to give the web service
a chance to see what the actual AtR looks like before it is made, so
the service can decide whether it is acceptable. In addition, the
client endpoint performs the preflight check as a security measure to
ensure that the visited service can understand the ATTEST method,
AHFs, and its implied security assurance.</t>
<t>To start HTTPA/2, a preflight request could be issued by a client
as optional to check whether the Web service, specified by URI in the
request line is TEE-aware and prepared for AtHS. If the client is a
web browser, the preflight request can be automatically issued when
the AtR qualifies as "to be preflighted." We need the preflight
transaction because it is a lightweight HTTP OPTIONS <xref target="RFC7231" format="default"/>
request, which will not consume a lot of computing resources to handle
compared to the AtR. Caching the preflight result can prevent
re-checking during a specified time window. In the case of
out-of-sync, the TService will result in an invalid signal for HTTPA
trusted requests. </t>
<t>Passing this check does not guarantee that this service can
successfully handle the AtR. For example, the TService may run out of
resources, or the client's cipher suites are not supported, and so
on.</t>
<t> The client can also use the preflight to detect the capabilities
of AtB, without implying any actual actions.</t>
<t/>
<figure anchor="ure-figure-3">
<name>Message Flow example for Preflight transaction</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Client-side Web Client Web TService Server-side
Verifier (HW-TEE,Attester) (HW-TEE,Attester) Verifier
| | | |
| |checkAttestMethod| |
| |---------------->| Optional request: |
| | | Access-Control-Request-Method |
| | | ATTEST |
| | | Access-Control-Request-Headers|
| | | ATTEST-Base-id, |
| | | ATTEST-Ticket, |
| | | ATTEST-Signature.. |
| | |------------------------------>|
| +===================PASS===============================+
| | | | HTTP 200 OK | |
| | | | Allow: ATTEST | |
| | | | Access-Control-Allow-Headers: | |
| | | | ATTEST-Base-id, | |
| | | | ATTEST-Ticket, | |
| | | | ATTEST-Signature... | |
| | | |<------------------------------| |
| | | HTTP 200 OK | | |
| | |<----------------| | |
| +======================================================+
| | | |
| +=================FAILURE==============================+
| | | | | |
| | | HTTP 405 METHOD_NOT_ALLOWED | |
| | |<----------------| | |
| | | | | |
| | | showErros | | |
| | |-------+ | | |
| | | | | | |
| | |<------+ | | |
| +======================================================+
| | | |
]]></artwork>
</figure>
<t>As shown in Figure 3, an
OPTIONS request should be honored by an HTTPA/2 compliant TService.
The preflight transaction has standard HFs to specify the method and
AHLs which will be sent out later to the same TService</t>
<t>if they are acceptable. Those HFs are described respectively as
follows:</t>
<t>1. HFs in the request message</t>
<t>(a) Access-Control-Request-Method</t>
<t>This HF carries a list of methods indicating that ATTEST method
will be used in the next request if the service can support it.</t>
<t>(b) Access-Control-Request-Headers</t>
<t>This HF carries a list of field names indicating that the AHFs will
be included in the next request if the service can support them.</t>
<t>2. HFs in the response message</t>
<t>(a) Allow</t>
<t>This HF carries a list of supported methods by the visiting
service. It must contain the ATTEST method for the client to proceed
with AtR; otherwise, the AtR is not acceptable by this service and
will be denied if received it.</t>
<t>(b) Access-Control-Allow-Headers</t>
<t>This HF carries a list of allowed AHFs. The client needs to check
that all of the requested AHFs should be contained in this resulting
field.</t>
<t>(c) Access-Control-Max-Age</t>
<t>This HF indicates how long the preflight check results can be
cached.</t>
<t/>
</section>
<section anchor="n-attest-handshake-aths-phase"
title="Attest Handshake (AtHS) Phase">
<t/>
<t>The AtHS phase contains a core transaction of HTTPA/2. In a single
round trip time (one RTT), the AtR and its response accomplish three
major tasks, including key exchange, AtB allocation, and AtQ exchange,
as shown in Figure 4.</t>
<figure anchor="ure-figure-4">
<name>Attest handshake (AtHS) transaction</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Client-side Web Client Web TService Server-side
Verifier (HW-TEE,Attester) (HW-TEE,Attester) Verifier
| | | |
| | | |
| | genExchangeKeys | +==========ATEST request=========+
| |----+ | |Attest-Version: [versions] |
| | | | |Attest-Date: [GMT] |
| |<---+ | |Attest-Signatures: sigs=[base64]|
| | | |Attest-Policies: [sec policies] |
| +=====OPTIONAL==========+ | |Attest-Base-Creation:[method] |
| | | genQuotes | | |Attest-Transport: [base64] |
| | |----+ | | |Attest-Random: [base64] |
| | | | | | |Attest-Quotes:quotes=[base64] |
| | |<---+ | | | max-age=[expireTime]|
| +=======================+ | |Attest-Cipher-Suites:[ciphrName]|
| | | |Attest-Supported-Groups[grNames]|
| | | |Attest-Key-Shares: [shared keys]|
| | sendAttestRequest | |Attest-Blocklist:identifie=[ids]|
| |------------------>| +================================+
| | | |
| | +======IF ATTESTING MUTUALLY==========+
| | | | sendQuote | |
| | | |------------------------------>| |
| | | | | |
| | | | getVerifyResult | |
| | | |<------------------------------| |
| | +=====================================+
| | |-------+ |
| | | | allocAttestBase |
| | |<------+ |
| | |-------+ |
| | | | genExchangeKeys |
| | |<------+ |
| | |-------+ |
| | | | genQuotes |
| | |<------+ |
| | |-------+ |
| | | | deriveKeys |
| | getAttestResponse |<------+ |
| sendQuote |<------------------| +=========HTTP 200 OK============+
|<----------| | |Attest-Version: [selected ver] |
| getVerif | | |Attest-Base-Id:[base64] |
| Result | | | max-age=[expireTime]|
|---------->| | |Attest-Transport: [base64] |
| +=====status is not 200=====+ | |Attest-Random: [base64] |
| |=======or unverified=======| | |Attest-Expires: [GMT] |
| | |----+ | | |Attest-Quotes:quotes=[base64] |
| | | | showErrors | | | max-age=[expireTime]|
| | |<---+ | | |Attest-Cipher-Suite:[ciphrNames]|
| +===========================+ | |Attest-Supported-Group:[grNames]|
| | | |Attest-Key-Share: [shared key] |
| |-------+ | |Attest-Secrets:[secrets="base64"|
| | |deriveKeys | | max-age=[expireTime]|
| |<------+ | |Attest-Cargo: [base64] |
| | | +================================+
| | | |
]]></artwork>
</figure>
<t/>
<t>1. Key Exchange</t>
<t>It is necessary to complete the key exchange process before any
sensitive information can be transmitted between the client and
TService. The exact steps within this will vary depending on the key
exchange algorithm used and the cipher suites supported by both
sides.</t>
<t>In HTTPA/2, the key exchange process follows TLS 1.3 <xref target="RFC8446" format="default"/> and
recommends a set of key exchange methods to meet evolving needs for
stronger security.</t>
<t>Insecure cipher suites have been excluded; all public-key-based key
exchange mechanisms now provide Perfect Forward Secrecy (PFS), e.g.,
Ephemeral Elliptic Curve Diffie-Hellman (ECDHE). Note that it is
mandatory that the fresh ephemeral keys are generated, used, and
destroyed afterward <xref target="RFC8422" format="default"/> inside the TEE of TService. When the key
exchange is completed, we recommend using the HMAC-based Extract-
and-Expand Key Derivation Function (HKDF) <xref target="RFC5869" format="default"/> as an underlying
primitive for key derivation. Also, note when a peer creates one or
more (EC)DHE public keys, it must do so in a correct and
standards-compliant manner. When a peer receives a set of (EC)DHE
public keys, it must validate that the public key is in the specified
group and has other required properties (e.g., it is not the group
identity).</t>
<t>We describe the key negotiation between the client and the TService
in terms of AHFs set in request and response, respectively, as
follows: </t>
<t>(a) AHFs in request message (or AtR):</t>
<t>i. Attest-Cipher-Suites</t>
<t>It is a list of cipher suites that indicates the AEAD
algorithm/HKDF supported by the client.</t>
<t>ii. Attest-Supported-Groups</t>
<t>A list of named groups <xref target="RFC7748" format="default"/> indicates the (EC)DHE groups
supported by the client for key exchange, ordered from most preferred
to least preferred. </t>
<t>iii. Attest-Key-Shares</t>
<t>Its value contains a list of the client's cryptographic parameters
for possible supported groups indicated in the AHL of
Attest-Supported-Groups for negotiation. We can refer to the
corresponding data structure described in TLS 1.3 <xref target="RFC8446" format="default"/>. It is a
time-consuming operation to generate those parameters.</t>
<t/>
<t>iv. Attest-Random</t>
<t>It is 32 bytes of a cryptographically random nonce, and the purpose
of the random nonce is to bind the master secret and the keys to this
particular handshake. This way mitigates the replay attack to the
handshake as long as each peer properly generates this random
nonce.</t>
<t/>
<t>(b) AHFs in response message</t>
<t>i. Attest-Cipher-Suite</t>
<t>It indicates the selected cipher suites, i.e., a symmetric
cipher/HKDF hash pair for HTTPA/2 message protection.</t>
<t>ii. Attest-Supported-Group</t>
<t>It indicates the selected named group to exchange ECDHE key share
generated by the TService.</t>
<t>iii. Attest-Key-Share</t>
<t>Its value contains the TService's cryptographic parameters
accordingly.</t>
<t>iv. Attest-Random</t>
<t>It takes the same mechanism as the Attest-Random in the request.
Instead, it is used by the client to derive the master secret and
other key materials. </t>
<t/>
<t>Note that anyone can observe this handshake process if the
byte-to-byte encryption does not protect it at L5, but it is safe
since the secrets of key exchange process will never be sent over the
wire.</t>
<t/>
<t>2. AtB Allocation</t>
<t>This task is responsible for resource allocation. The upfront
TService needs to prepare essential resources before assigning a
unique AtB identifier to the AtB, which the client uses to ask
TService to process its sensitive data on this AtB, AHF is part of
AHL</t>
<t/>
<t>(a) AHFs in request message (or AtR):</t>
<t>i. Attest-Policies</t>
<t>It can contain various security policies, which this AtB of
TService can selectively support. There are two aspects to consider as
follows:</t>
<t>
<strong>Service instances attestation</strong>
</t>
<t>direct: all instances should be verified by the client.</t>
<t>Indirect: only the contact instance(a proxy instance could be used
for attesting other instances) should be verified by the client
remotely.</t>
<t>
<strong>Un-trusted requests</strong>
</t>
<t>allowUntrustedReq: it allows UtR to be handled by the TService on
this AtB (disabled by default).</t>
<t/>
<t>ii. Attest-Base-Creation</t>
<t>It specifies a method used for the creation of AtB. There might be
several options available to select:</t>
<t/>
<t>
<strong>new</strong>
</t>
<t>It means that the AtB should be newly created for the client to
use. If the contact TService is new, it can be assigned to this client
immediately.</t>
<t/>
<t>
<strong>reuse</strong>
</t>
<t>This option allows reusable AtB to be used by this client, but the
AtB should ensure that all traces associated with the previous client
are erased.</t>
<t/>
<t>So far, there is no such TEE, which can achieve this security
feature strictly, and we cannot fully rely on software to emulate it.
As a result, the client should evaluate the risks before specifying
this option.</t>
<t/>
<t>
<strong>shared</strong>
</t>
<t>A shareable AtB can be allocated to this client. The client doesn't
care whether it is a clean base or not,so use it with caution.</t>
<t>iii. Attest-Blocklist</t>
<t>It indicates a list of blocked identities and another type of
identifier which allows TService to filter out unqualified AtB
beforehand. This feature is used to optimize the performance of AtB
allocation, as it is quite expensive and inefficient to rely only on
the client to collect a set of TService instances by allow list using
the trial and error method.</t>
<t/>
<t>(b) AHFs in response message:</t>
<t>i. Attest-Base-ID</t>
<t>This identifier signifies the allocated AtB, which has been tied to
this particular client who sent the AtHS request. It should be used in
subsequent HTTPA/2 requests to ensure those requests can be
efficiently dispatched into TServices. Given that the HTTPA/2 request
dispatcher may not be trustworthy and be unable to check its
integrity. As a result, it cannot guarantee that those requests could
be delivered to their matched AtBs. To remedy this problem, the
dispatcher should be capable of identifying as invalid AtB ID as
possible, and the receiving TService should validate it right after
the integrity check (see <tt> REF _Ref107244144 \h \* MERGEFORMAT
Figure 5</tt> and <tt> REF _Ref107244151 \h \* MERGEFORMAT Figure
6</tt>).</t>
<t/>
<t>Note that the max-age directive set here indicates how long this
AtB could be kept alive at the server-side, it follows GMT, and the
unit is second.</t>
<t/>
<t>3. AtQ Exchange</t>
<t>In HTTPA/2, a successful RA increases the client's confidence by
assuring the targeting services are running inside a trustworthy AtB.
The client can also determine the level of trust in the security
assurances provided by TServices through AtB.</t>
<t>The RA is mainly aimed at provision secrets to a TEE. In this
solution, we leverage this mechanism to set it as the root trust of
the HTTPA/2 transactions instead of certificate-based trust, e.g.,
TLS. To facilitate it, we integrate the RA with the key exchange
mechanism above to perform a handshake, which passes the assurance to
derive ephemeral key materials. Those keys can be, in turn, used to
protect secrets and sensitive data designated by the client or
TService on either direction.</t>
<t>During the RA process, the AtQ plays a key role in attesting
TService. It provides evidence (quote) to prove the authenticity of
the relevant TService and provides assurance that the TService is a
trustworthy client can just rely on it to decide whether the TService
is a trustworthy peer or not.</t>
<t>To appraise AtQ, we need a trusted authority to be the verifier to
perform the process of AtQ verification and report issues on this AtQ,
e.g., TCB issues. The verification result produced by the verifier
should be further assessed by the client according to its
pre-configured policy rules and applied security contexts. Notably,
the TService should ensure the integrity and authenticity of all AHLs
of AtR, and its response through a piece of user-defined information,
called Quote User Defined Data (QUDD) of AtQ, the QUDD can provide
extra identities specific to a TService. Therefore, the AtQ can, in
turn, help protect the integrity of Attest Header Lines (AHLs). The
following AHFs should be supported by HTTPA/2 protocol for RA request
message is optional.</t>
<t>(a) AHFs in request message (or AtR):</t>
<t>i. Attest-Quotes</t>
<t>It can only appear in mHTTPA/2 mode to indicate a set of AtQs
generated from the TClients for targeting TService to verify. These
quotes should be used to ensure IntAuth of the AHLs of this AtR
through their QUDD.</t>
<t>Note that the max-age directive indicates when these quotes are
outdated, and its cached verification results should be cleared up
from AtB to avoid broken assurance. In addition, all client-side
quotes must be verified by the server-side verifier and validated by
TServices before an AtB ID can be issued.</t>
<t/>
<t>(b) AHFs in response message</t>
<t>i. Attest-Quotes</t>
<t>An AtB must present its AtQs to the client for client-side
verification. The IntAuth of both AHLs of the AtR and its response
should be ensured by its QUDDs to protect the transaction
completely.</t>
<t>The client must verify the AtQ to authenticate its identity of
remote AtB. The client should not trust anything received from
TService before AtQs are successfully verified and evaluated by the
trust authority. Whether the integrity of AHLs is held should be
determined by client-side security policies. Note that the TService
quotes can be selectively encrypted in its parts through TrC to hide
their identity information.</t>
<t>There are several remaining AHFs, which are important to this
transaction as they provide other necessary information and useful
security properties:</t>
<t/>