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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
|
<pre>Internet Engineering Task Force (IETF) N. Cam-Winget
Request for Comments: 7171 Cisco Systems
Category: Standards Track P. Sangster
ISSN: 2070-1721 Symantec Corporation
May 2014
<span class="h1">PT-EAP: Posture Transport (PT) Protocol</span>
<span class="h1">for Extensible Authentication Protocol (EAP) Tunnel Methods</span>
Abstract
This document specifies PT-EAP, a Posture Transport (PT) protocol
based on the Extensible Authentication Protocol (EAP) and designed to
be used only inside an EAP tunnel method protected by Transport Layer
Security (TLS). The document also describes the intended
applicability of PT-EAP.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7171">http://www.rfc-editor.org/info/rfc7171</a>.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Cam-Winget & Sangster Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7171">RFC 7171</a> NEA PT-EAP May 2014</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Prerequisites . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. Message Diagram Conventions . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.3">1.3</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.4">1.4</a>. Conventions Used in This Document . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-1.5">1.5</a>. Compatibility with Other Specifications . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2">2</a>. Use of PT-EAP . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Definition of PT-EAP . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. Protocol Overview . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. Version Negotiation . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.3">3.3</a>. PT-EAP Message Format . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.4">3.4</a>. Preventing MITM Attacks with Channel Bindings . . . . . . <a href="#page-8">8</a>
<a href="#section-4">4</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.1">4.1</a>. Trust Relationships . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.1.1">4.1.1</a>. Posture Transport Client . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.1.2">4.1.2</a>. Posture Transport Server . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.2">4.2</a>. Threats and Countermeasures . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.2.1">4.2.1</a>. Message Confidentiality . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.2.2">4.2.2</a>. Message Fabrication . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.2.3">4.2.3</a>. Message Modification . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4.2.4">4.2.4</a>. Denial of Service . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4.2.5">4.2.5</a>. NEA Asokan Attacks . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-4.3">4.3</a>. Candidate EAP Tunnel Method Protections . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-4.4">4.4</a>. Security Claims for PT-EAP as per <a href="./rfc3748">RFC 3748</a> . . . . . . . <a href="#page-14">14</a>
<a href="#section-5">5</a>. Requirements for EAP Tunnel Methods . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-6">6</a>. Privacy Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-7">7</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-7.1">7.1</a>. Registry for PT-EAP Versions . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-8">8</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-9">9</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-9.1">9.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-9.2">9.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document specifies PT-EAP, a Posture Transport (PT) protocol
protected by a TLS-protected EAP tunnel method. The PT protocol in
the Network Endpoint Assessment (NEA) architecture is responsible for
transporting Posture Broker (PB-TNC [<a href="./rfc5793" title=""PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)"">RFC5793</a>]) batches, often
containing Posture Attributes (PA-TNC [<a href="./rfc5792" title=""PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)"">RFC5792</a>]), across the network
between the NEA Client and NEA Server. The PT-EAP protocol must be
protected by an outer TLS-based EAP tunnel method to ensure the
exchanged messages are protected from a variety of threats from
hostile intermediaries.
<span class="grey">Cam-Winget & Sangster Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7171">RFC 7171</a> NEA PT-EAP May 2014</span>
NEA protocols are intended to be used both for pre-admission
assessment of endpoints joining the network and assessment of
endpoints already present on the network. In order to support both
usage models, two types of PT protocols are needed. One type of PT,
PT-TLS [<a href="./rfc6876" title=""A Posture Transport Protocol over TLS (PT-TLS)"">RFC6876</a>], operates after the endpoint has an assigned IP
address, layering on top of the IP protocol to carry a NEA exchange.
The other type of PT operates before the endpoint gains any access to
the IP network. This specification defines PT-EAP, the PT protocol
used to assess endpoints before they gain access to the network.
PT-EAP is an inner EAP [<a href="./rfc3748" title=""Extensible Authentication Protocol (EAP)"">RFC3748</a>] method designed to be used inside a
protected tunnel such as Tunnel EAP (TEAP) [<a href="./rfc7170" title=""Tunnel Extensible Authentication Protocol (TEAP) Version 1"">RFC7170</a>], EAP Flexible
Authentication via Secure Tunneling (EAP-FAST) [<a href="./rfc4851" title=""The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)"">RFC4851</a>], or EAP
Tunneled Transport Layer Security (EAP-TTLS) [<a href="./rfc5281" title=""Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)"">RFC5281</a>]. That is, an
outer EAP method is typically a TLS-based EAP method that first
establishes a protected tunnel by which other conversations, such as
other EAP methods (e.g., "inner" EAP methods) can ensue under the
tunnel protection.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Prerequisites</span>
This document does not define an architecture or reference model.
Instead, it defines a protocol that works within the reference model
described in the NEA Requirements specification [<a href="./rfc5209" title=""Network Endpoint Assessment (NEA): Overview and Requirements"">RFC5209</a>]. The
reader is assumed to be thoroughly familiar with that document.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Message Diagram Conventions</span>
This specification defines the syntax of PT-EAP messages using
diagrams. Each diagram depicts the format and size of each field in
bits. Implementations MUST send the bits in each diagram as they are
shown, traversing the diagram from top to bottom and then from left
to right within each line (which represents a 32-bit quantity).
Multi-byte fields representing numeric values MUST be sent in network
(big-endian) byte order.
Descriptions of bit field (e.g., flag) values are described referring
to the position of the bit within the field. These bit positions are
numbered from the most significant bit through the least significant
bit so a one octet field with only bit 0 set has the value 0x80.
<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>. Terminology</span>
This document reuses many terms defined in the NEA Requirements
document [<a href="./rfc5209" title=""Network Endpoint Assessment (NEA): Overview and Requirements"">RFC5209</a>], such as "Posture Transport Client" and "Posture
Transport Server". The reader is assumed to have read that document
and understood it.
<span class="grey">Cam-Winget & Sangster Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7171">RFC 7171</a> NEA PT-EAP May 2014</span>
When defining the PT-EAP method, this specification does not use the
terms "EAP peer" and "EAP authenticator". Instead, it uses the terms
"NEA Client" and "NEA Server" since those are considered to be more
familiar to NEA WG participants. However, these terms are equivalent
for the purposes of this specification. The part of the NEA Client
that terminates PT-EAP (generally in the Posture Transport Client) is
the EAP peer for PT-EAP. The part of the NEA Server that terminates
PT-EAP (generally in the Posture Transport Server) is the EAP
authenticator for PT-EAP.
<span class="h3"><a class="selflink" id="section-1.4" href="#section-1.4">1.4</a>. Conventions Used in This Document</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h3"><a class="selflink" id="section-1.5" href="#section-1.5">1.5</a>. Compatibility with Other Specifications</span>
One of the goals of the NEA effort is to deliver a single set of
endpoint assessment standards, agreed upon by all parties. For this
reason, the authors understand that the Trusted Computing Group (TCG)
will be replacing its existing posture transport protocols with new
versions that are equivalent to and interoperable with the NEA
specifications.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Use of PT-EAP</span>
PT-EAP is designed to encapsulate PB-TNC batches in a simple EAP
method that can be carried within EAP tunnel methods. The EAP tunnel
methods provide confidentiality and message integrity, so PT-EAP does
not have to do so. Therefore, PT-EAP MUST be used inside a TLS-based
EAP tunnel method that provides strong cryptographic authentication
(possibly server only), message integrity, and confidentiality
services.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Definition of PT-EAP</span>
The PT-EAP protocol operates between a Posture Transport Client and a
Posture Transport Server, allowing them to send PB-TNC batches to
each other over an EAP tunnel method. When PT-EAP is used, the
Posture Transport Client in the NEA reference model acts as an EAP
peer (terminating the PT-EAP method on the endpoint), and the Posture
Transport Server acts as an EAP authenticator (terminating the PT-EAP
method on the NEA Server).
This section describes and defines the PT-EAP method. First, it
provides a protocol overview. Second, it describes specific features
like version negotiation. Third, it gives a detailed packet
<span class="grey">Cam-Winget & Sangster Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7171">RFC 7171</a> NEA PT-EAP May 2014</span>
description. Finally, it describes how the tls-unique channel
binding [<a href="./rfc5929" title=""Channel Bindings for TLS"">RFC5929</a>] may be used to bind PA-TNC exchanges to the EAP
tunnel method, defeating man-in-the-middle (MITM) attacks such as the
Asokan attack [<a href="#ref-Asokan" title=""Man-in-the-Middle Attacks in Tunneled Authentication Protocols"">Asokan</a>].
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Protocol Overview</span>
PT-EAP has two phases that follow each other in strict sequence:
negotiation and data transport.
The PT-EAP method begins with the negotiation phase. The NEA Server
starts this phase by sending a PT-EAP Start message: an EAP Request
message of type PT-EAP with the S (Start) flag set. The NEA Server
also sets the Version field as described in <a href="#section-3.2">Section 3.2</a>. This is the
only message in the negotiation phase.
The data transport phase is the only phase of PT-EAP where PB-TNC
batches are allowed to be exchanged. This phase always starts with
the NEA Client sending a PB-TNC batch to the NEA Server. The NEA
Client and NEA Server then take turns sending a PB-TNC batch. The
data transport phase always ends with an EAP Response message from
the NEA Client to the NEA Server. The Data field of this message may
have zero length if the NEA Server has just sent the last PB-TNC
batch in the PB-TNC exchange.
Note that the success of PT-EAP does not mean the overall
authentication (using the outer EAP tunnel method) will succeed.
Neither does the failure of PT-EAP mean that the overall
authentication will fail. Success of the overall authentication
depends on the policy configured by the administrator.
At the end of the PT-EAP method, the NEA Server will indicate success
or failure to the EAP tunnel method. Some EAP tunnel methods may
provide explicit confirmation of inner method success; others may
not. This is out of scope for the PT-EAP method specification.
Successful completion of PT-EAP does not imply successful completion
of the overall authentication nor does PT-EAP failure imply overall
failure. This depends on the administrative policy in place.
The NEA Server and NEA Client may engage in an abnormal termination
of the PT-EAP exchange at any time by simply stopping the exchange.
This may also require terminating the EAP tunnel method, depending on
the capabilities of the EAP tunnel method.
<span class="grey">Cam-Winget & Sangster Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7171">RFC 7171</a> NEA PT-EAP May 2014</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Version Negotiation</span>
PT-EAP version negotiation takes place in the first PT-EAP message
sent by the NEA Server (the Start message) and the first PT-EAP
message sent by the NEA Client (the response to the Start message).
The NEA Server MUST set the Version field in the Start message to the
maximum PT-EAP version that the NEA Server supports and is willing to
accept.
The NEA Client chooses the PT-EAP version to be used for the exchange
and places this value in the Version field in its response to the
Start message. The NEA Client SHOULD choose the value sent by the
NEA Server if the NEA Client supports it. However, the NEA Client
MAY set the Version field to a value less than the value sent by the
NEA Server (for example, if the NEA Client only supports lesser
PT-EAP versions). If the NEA Client only supports PT-EAP versions
greater than the value sent by the NEA Server, the NEA Client MUST
abnormally terminate the EAP negotiation.
If the version sent by the NEA Client is not acceptable to the NEA
Server, the NEA Server MUST terminate the PT-EAP session immediately.
Otherwise, the version sent by the NEA Client is the version of
PT-EAP that MUST be used. Both the NEA Client and the NEA Server
MUST set the Version field to the chosen version number in all
subsequent PT-EAP messages in this exchange.
This specification defines version 1 of PT-EAP. Version 0 is
reserved and MUST never be sent. New versions of PT-EAP (values 2-7)
may be defined by Standards Action, as defined in [<a href="./rfc5226" title="">RFC5226</a>].
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. PT-EAP Message Format</span>
This section provides a detailed description of the fields in a
PT-EAP message. For a description of the diagram conventions used
here, see <a href="#section-1.2">Section 1.2</a>. Since PT-EAP is an EAP method, the first four
fields (e.g., Code, Identifier, Length, and Type as shown in
Figure 1) in each message are mandated by and defined in EAP. The
other fields, e.g., Flags, Version, and Data are specific to PT-EAP.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Ver | Data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PT-EAP Message Format
<span class="grey">Cam-Winget & Sangster Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7171">RFC 7171</a> NEA PT-EAP May 2014</span>
Code
The Code field is one octet and identifies the type of the EAP
message. The only values used for PT-EAP are:
1 Request
2 Response
Identifier
The Identifier field is one octet and aids in matching Responses
with Requests.
Length
The Length field is two octets and indicates the length in octets
of this PT-EAP message, starting from the Code field.
Type
54 (EAP Method Type [<a href="./rfc3748" title=""Extensible Authentication Protocol (EAP)"">RFC3748</a>] assignment for PT-EAP).
Flags
+-+-+-+-+-+
|S R R R R|
+-+-+-+-+-+
S: Start
Indicates the beginning of a PT-EAP exchange. This flag MUST be
set only for the first message from the NEA Server. If the S flag
is set, the EAP message MUST NOT contain Data.
R: Reserved
This flag MUST be set to 0 and ignored upon receipt.
Version
This field is used for version negotiation, as described in
<a href="#section-3.2">Section 3.2</a>.
<span class="grey">Cam-Winget & Sangster Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7171">RFC 7171</a> NEA PT-EAP May 2014</span>
Data
Variable length data. This field is processed by the PB layer and
MUST include PB-TNC messages. For more information see PB-TNC
[<a href="./rfc5793" title=""PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)"">RFC5793</a>].
The length of the Data field in a particular PT-EAP message may be
determined by subtracting the length of the PT-EAP header fields
from the value of the two-octet Length field.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Preventing MITM Attacks with Channel Bindings</span>
As described in the NEA Asokan Attack Analysis [<a href="./rfc6813" title=""The Network Endpoint Assessment (NEA) Asokan Attack Analysis"">RFC6813</a>], a
sophisticated MITM attack can be mounted against NEA systems. The
attacker forwards PA-TNC messages from a healthy machine through an
unhealthy one so that the unhealthy machine can gain network access.
Because there are easier attacks on NEA systems, like having the
unhealthy machine lie about its configuration, this attack is
generally only mounted against machines with an External Measurement
Agent (EMA). The EMA is a separate entity, difficult to compromise,
that measures and attests to the configuration of the endpoint.
To protect against NEA Asokan attacks, it is necessary for the
Posture Broker on an EMA-equipped endpoint to pass the tls-unique
channel binding [<a href="./rfc5929" title=""Channel Bindings for TLS"">RFC5929</a>] from PT-EAP's tunnel method to the EMA.
This value can then be included in the EMA's attestation so that the
Posture Validator responsible may then confirm that the value matches
the tls-unique channel binding for its end of the tunnel. If the
tls-unique values of the NEA Client and NEA Server match and this is
confirmed by the EMA, then the posture sent by a trustworthy EMA (and
thus the NEA Client) is from the same endpoint as the client side of
the TLS connection (since the endpoint knows the tls-unique value) so
no MITM is forwarding posture. If they differ, an attack has been
detected, and the Posture Validator SHOULD fail its verification.
Note that tls-unique, as opposed to invoking a mutual cryptographic
binding, is used as there is no keying material being generated by
PT-EAP (the method is defined to facilitate the transport of posture
data and is not an authentication method). However, the NEA Client
may host an EMA that can be used as the means to cryptographically
bind the tls-unique content that may be validated by the Posture
Validator interfacing with the EAP Server. The binding of the
tls-unique to the client authentication prevents the client's message
from being used in another context. This prevents a poorly
configured client from unintentionally compromising the NEA system.
Strong mutual authentication of the NEA Server and Client is still
REQUIRED to prevent the disclosure of possibly sensitive NEA Client
information to an attacker.
<span class="grey">Cam-Winget & Sangster Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7171">RFC 7171</a> NEA PT-EAP May 2014</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
This section discusses the major threats and countermeasures provided
by PT-EAP. As discussed throughout the document, the PT-EAP method
is designed to run inside an EAP tunnel method that is capable of
protecting the PT-EAP protocol from many threats. Since the EAP
tunnel method will be specified separately, this section describes
the considerations on the EAP tunnel method but does not evaluate its
ability to meet those requirements. The security considerations and
requirements for NEA can be found in [<a href="./rfc5209" title=""Network Endpoint Assessment (NEA): Overview and Requirements"">RFC5209</a>].
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Trust Relationships</span>
In order to understand where security countermeasures are necessary,
this section starts with a discussion of where the NEA architecture
envisions some trust relationships between the processing elements of
the PT-EAP protocol. The following sub-sections discuss the trust
properties associated with each portion of the NEA reference model
directly involved with the processing of the PT-EAP protocol flowing
inside an EAP tunnel.
<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. Posture Transport Client</span>
The Posture Transport Client is trusted by the Posture Broker Client
to:
o Not disclose to unauthorized parties, fabricate, or alter the
contents of the PB-TNC batches received from the network.
o Not observe, fabricate, or alter the PB-TNC batches passed down
from the Posture Broker Client for transmission on the network.
o Transmit on the network any PB-TNC batches passed down from the
Posture Broker Client.
o Provide configured security protections (e.g., authentication,
integrity, and confidentiality) for the Posture Broker Client's
PB-TNC batches sent on the network.
o Expose the authenticated identity of the Posture Transport Server
to the Posture Broker Client.
o Verify the security protections placed upon messages received from
the network to ensure the messages are authentic and protected
from attacks on the network.
o Deliver to the Posture Broker Client the PB-TNC batches received
from the network so long as they are properly security protected.
<span class="grey">Cam-Winget & Sangster Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7171">RFC 7171</a> NEA PT-EAP May 2014</span>
o Provide a secure, reliable, "in-order delivery", full-duplex
transport for the Posture Broker Client's messages.
Since the Posture Transport Server can not validate the
trustworthiness of the Posture Transport Client, the Posture
Transport Server should protect itself appropriately.
<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>. Posture Transport Server</span>
The Posture Transport Server is trusted by the Posture Broker Server
to:
o Not observe, fabricate, or alter the contents of the PB-TNC
batches received from the network.
o Not observe, fabricate, or alter the PB-TNC batches passed down
from the Posture Broker Server for transmission on the network.
o Transmit on the network any PB-TNC batches passed down from the
Posture Broker Server.
o Ensure PB-TNC batches received from the network are properly
protected from a security perspective.
o Provide configured security protections (e.g., authentication,
integrity, and confidentiality) for the Posture Broker Server's
messages sent on the network.
o Expose the authenticated identity of the Posture Transport Client
to the Posture Broker Server.
o Verify the security protections placed upon messages received from
the network to ensure the messages are authentic and protected
from attacks on the network.
Since the Posture Transport Client can not validate the
trustworthiness of the Posture Transport Server, the Posture
Transport Client should protect itself appropriately.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Threats and Countermeasures</span>
Beyond the trusted relationships assumed in <a href="#section-4.1">Section 4.1</a>, the PT-EAP
EAP method faces a number of potential security attacks that could
require security countermeasures.
Generally, the PT protocol is responsible for providing strong
security protections for all of the NEA protocols so any threats to
PT's ability to protect NEA protocol messages could be very damaging
<span class="grey">Cam-Winget & Sangster Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7171">RFC 7171</a> NEA PT-EAP May 2014</span>
to deployments. For the PT-EAP method, most of the cryptographic
security is provided by the outer EAP tunnel method, and PT-EAP is
encapsulated within the protected tunnel. Therefore, this section
highlights the cryptographic requirements that need to be met by the
EAP tunnel method carrying PT-EAP in order to meet the NEA PT
requirements.
Once the message is delivered to the Posture Broker Client or Posture
Broker Server, the Posture Brokers are trusted to properly and safely
process the messages.
<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>. Message Confidentiality</span>
When PT-EAP messages are sent over unprotected network links or span
local software stacks that are not trusted, the contents of the
messages may be subject to information theft by an intermediary
party. This theft could result in information being recorded for
future use or analysis by an adversary. Messages observed by
eavesdroppers could contain information that exposes potential
weaknesses in the security of the endpoint or system fingerprinting
information easing the ability of the attacker to employ attacks more
likely to be successful against the endpoint. The eavesdropper might
also learn information about the endpoint or network policies that
either singularly or collectively is considered sensitive
information. For example, if PT-EAP is carried by an EAP tunnel
method that does not provide confidentiality protection, an adversary
could observe the PA-TNC attributes included in the PB-TNC batch and
determine that the endpoint is lacking patches or that particular
sub-networks have more lenient policies.
In order to protect against NEA assessment message theft, the EAP
tunnel method carrying PT-EAP must provide strong cryptographic
authentication, integrity, and confidentiality protection. The use
of bidirectional authentication in the EAP tunnel method carrying
PT-EAP ensures that only properly authenticated and authorized
parties may be involved in an assessment message exchange. When
PT-EAP is carried within a cryptographically protected EAP tunnel
method like EAP-FAST or EAP-TTLS, all of the contents of PB-TNC and
PA-TNC protocol messages are hidden from potential theft by
intermediaries lurking on the network.
<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>. Message Fabrication</span>
Attackers on the network or present within the NEA system could
introduce fabricated PT-EAP messages intending to trick or create a
denial of service against aspects of an assessment. For example, an
adversary could attempt to insert a PT-EAP message to tell a NEA
Server that the endpoint is totally infected. This could cause the
<span class="grey">Cam-Winget & Sangster Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7171">RFC 7171</a> NEA PT-EAP May 2014</span>
device to be blocked from accessing a critical resource, which would
be a denial of service.
The EAP tunnel method carrying a PT-EAP method needs to provide
strong security protections for the complete message exchange over
the network. These security protections prevent an intermediary from
being able to insert fake messages into the assessment. See
<a href="#section-5">Section 5</a> for more details on the EAP tunnel requirements.
<span class="h4"><a class="selflink" id="section-4.2.3" href="#section-4.2.3">4.2.3</a>. Message Modification</span>
This attack could allow an active attacker capable of intercepting a
message to modify a PT-EAP message or transported PA-TNC attribute to
a desired value to ease the compromise of an endpoint. Without the
ability for message recipients to detect whether a received message
contains the same content as what was originally sent, active
attackers can stealthily modify the attribute exchange.
PT-EAP leverages the EAP tunnel method (e.g., TEAP, EAP-FAST, or EAP-
TTLS) to provide strong authentication and integrity protections as a
countermeasure to this threat. The bidirectional authentication
prevents the attacker from acting as an active MITM to the protocol
that could be used to modify the message exchange. The strong
integrity protections offered by the TLS-based EAP tunnel method
allow the PT-EAP message recipients to detect message alterations by
other types of network-based adversaries. Because PT-EAP does not
itself provide explicit integrity protection for the PT-EAP payload,
an EAP tunnel method that offers strong integrity protection is
needed to mitigate this threat.
<span class="h4"><a class="selflink" id="section-4.2.4" href="#section-4.2.4">4.2.4</a>. Denial of Service</span>
A variety of types of denial-of-service attacks are possible against
PT-EAP if the message exchange is left unprotected while traveling
over the network. The Posture Transport Client and Posture Transport
Server are trusted not to participate in the denial of service of the
assessment session, leaving the threats to come from the network.
The PT-EAP method primarily relies on the outer EAP tunnel method to
provide strong authentication (at least of one party), and deployers
are expected to leverage other EAP methods to authenticate the other
party (typically the client) within the protected tunnel. The use of
a protected bidirectional authentication will prevent unauthorized
parties from participating in a PT-EAP exchange.
After the cryptographic authentication by the EAP tunnel method, the
session can be protected cryptographically to provide confidentiality
and source authenticity. Such protection prevents undetected
<span class="grey">Cam-Winget & Sangster Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7171">RFC 7171</a> NEA PT-EAP May 2014</span>
modification that could create a denial-of-service situation.
However, it is possible for an adversary to alter the message flows,
causing each message to be rejected by the recipient because it fails
the integrity checking.
<span class="h4"><a class="selflink" id="section-4.2.5" href="#section-4.2.5">4.2.5</a>. NEA Asokan Attacks</span>
As described in <a href="#section-3.4">Section 3.4</a> and in the NEA Asokan Attack Analysis
[<a href="./rfc6813" title=""The Network Endpoint Assessment (NEA) Asokan Attack Analysis"">RFC6813</a>], a sophisticated MITM attack can be mounted against NEA
systems. The attacker forwards PA-TNC messages from a healthy
machine through an unhealthy one so that the unhealthy machine can
gain network access. <a href="#section-3.4">Section 3.4</a> and [<a href="./rfc6813" title=""The Network Endpoint Assessment (NEA) Asokan Attack Analysis"">RFC6813</a>] provide a detailed
description of this attack and of the countermeasures that can be
employed against it.
Because lying endpoint attacks are much easier than Asokan attacks
and an effective countermeasure against lying endpoint attacks is the
use of an External Measurement Agent (EMA), countermeasures against
an Asokan attack are not necessary unless an EMA is in use. However,
PT-EAP implementers may not know whether an EMA will be used with
their implementation. Therefore, PT-EAP implementers SHOULD support
these countermeasures by providing the value of the tls-unique
channel binding to higher layers in the NEA reference model: Posture
Broker Clients, Posture Broker Servers, Posture Collectors, and
Posture Validators. If the tls-unique channel binding is
implemented, it must be verified before any other attestations are
evaluated.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Candidate EAP Tunnel Method Protections</span>
This section discusses how PT-EAP is used within various EAP tunnel
methods to meet the PT requirements in <a href="#section-5">Section 5</a>.
TEAP [<a href="./rfc7170" title=""Tunnel Extensible Authentication Protocol (TEAP) Version 1"">RFC7170</a>], EAP-FAST [<a href="./rfc4851" title=""The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)"">RFC4851</a>], and EAP-TTLS [<a href="./rfc5281" title=""Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)"">RFC5281</a>] make use
of TLS [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] to protect the transport of information between the
NEA Client and NEA Server. Each of these EAP tunnel methods has two
phases. In the first phase, a TLS tunnel is established between the
NEA Client and NEA Server. In the second phase, the tunnel is used
to pass other information. PT-EAP requires that establishing this
tunnel include at least an authentication of the NEA Server by the
NEA Client.
The phase two dialog may include authentication of the user by doing
other EAP methods or, in the case of EAP-TTLS, by using EAP or non-
EAP authentication dialogs. PT-EAP is also carried by the phase two
tunnel, allowing the NEA assessment to be within an encrypted and
integrity-protected transport.
<span class="grey">Cam-Winget & Sangster Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7171">RFC 7171</a> NEA PT-EAP May 2014</span>
With all these methods (e.g., TEAP [<a href="./rfc7170" title=""Tunnel Extensible Authentication Protocol (TEAP) Version 1"">RFC7170</a>], EAP-FAST [<a href="./rfc4851" title=""The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)"">RFC4851</a>], and
EAP-TTLS [<a href="./rfc5281" title=""Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)"">RFC5281</a>]), a cryptographic key is derived from the
authentication that may be used to secure later transmissions. Each
of these methods employs at least a NEA Server authentication using
an X.509 certificate. Within each EAP tunnel method will exist a set
of inner EAP methods. These inner methods may perform additional
security handshakes including more granular authentications or
exchanges of integrity information (such as PT-EAP). At some point
after the conclusion of each inner EAP method, some of the methods
will export the established secret keys to the outer tunnel method.
It's expected that the outer method will cryptographically mix these
keys into any keys it is currently using to protect the session and
perform a final operation to determine whether both parties have
arrived at the same mixed key. This cryptographic binding of the
inner method results to the outer method's keys is essential for
detection of conventional (non-NEA) Asokan attacks.
TEAP [<a href="./rfc7170" title=""Tunnel Extensible Authentication Protocol (TEAP) Version 1"">RFC7170</a>] is the mandatory-to-implement EAP tunnel method.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Security Claims for PT-EAP as per <a href="./rfc3748">RFC 3748</a></span>
This section summarizes the security claims for this specification,
as required by <a href="./rfc3748#section-7.2">[RFC3748], Section 7.2</a>:
Auth. mechanism: None
Ciphersuite negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: No
Confidentiality: No
Key derivation: No
Key strength: N/A
Dictionary attack resistant: N/A
Fast reconnect: No
Crypt. binding: N/A
Session independence: N/A
Fragmentation: No
Channel binding: No
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Requirements for EAP Tunnel Methods</span>
Because the PT-EAP inner method described in this specification
relies on the outer EAP tunnel method for a majority of its security
protections, this section reiterates the PT requirements that MUST be
met by the IETF standard EAP tunnel method for use with PT-EAP.
<span class="grey">Cam-Winget & Sangster Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7171">RFC 7171</a> NEA PT-EAP May 2014</span>
TEAP [<a href="./rfc7170" title=""Tunnel Extensible Authentication Protocol (TEAP) Version 1"">RFC7170</a>] is a Standards Track EAP tunnel method that satisfies
NEA's requirements and is the mandatory-to-implement EAP tunnel
method.
The security requirements described in this specification MUST be
implemented in any product claiming to be PT-EAP compliant. The
decision of whether a particular deployment chooses to use these
protections is a deployment issue. A customer may choose to avoid
potential deployment issues or performance penalties associated with
the use of cryptography when the required protection has been
achieved through other mechanisms (e.g., physical isolation). If
security mechanisms may be deactivated by policy, an implementation
SHOULD offer an interface to query how a message will be (or was)
protected by PT so higher-layer NEA protocols can factor this into
their decisions.
<a href="./rfc5209">RFC 5209</a> [<a href="./rfc5209" title=""Network Endpoint Assessment (NEA): Overview and Requirements"">RFC5209</a>] includes the following requirement that is to be
applied during the selection of the EAP tunnel method(s) used in
conjunction with PT-EAP:
PT-2: The PT protocol MUST be capable of supporting mutual
authentication, integrity, confidentiality, and replay protection
of the PB messages between the Posture Transport Client and the
Posture Transport Server.
Note that mutual authentication could be achieved by a combination of
a strong authentication of one party (e.g., server authentication
while establishing the TLS-based tunnel) by the EAP tunnel method in
conjunction with a second authentication of the other party (e.g.,
client authentication inside the protected tunnel) by another EAP
method running prior to PT-EAP.
Having the Posture Transport Client always authenticate the Posture
Transport Server provides assurance to the NEA Client that the NEA
Server is authentic (not a rogue or MITM) prior to disclosing secret
or potentially privacy-sensitive information about what is running or
configured on the endpoint. However, the NEA Server's policy may
allow for the delay of the authentication of the NEA Client until a
suitable protected channel has been established allowing for non-
cryptographic NEA Client credentials (e.g., username/password) to be
used. Whether the communication channel is established with mutual
or server-side-only authentication, the resulting channel needs to
provide strong integrity and confidentiality protection to its
contents. These protections are to be bound to at least the
authentication of the NEA Server by the NEA Client, so the session is
cryptographically bound to a particular authentication event.
<span class="grey">Cam-Winget & Sangster Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7171">RFC 7171</a> NEA PT-EAP May 2014</span>
The EAP tunnel method carrying PT-EAP MUST provide strong
cryptographic authentication, integrity, and confidentiality
protection to protect against NEA assessment message theft as
described in <a href="#section-4.2.1">Section 4.2.1</a>. The cryptographically protected EAP
tunnel ensures that all of the PA-TNC and PB-TNC protocol messages
are hidden from intermediaries wanting to steal NEA data.
To support countermeasures against NEA Asokan attacks as described in
<a href="#section-3.4">Section 3.4</a>, the EAP tunnel method used with PT-EAP will need to
support generation of the tls-unique value to be used with the higher
layers of the NEA reference model. This should not be a high bar
since all EAP tunnel methods currently support this, but not all
implementations of those methods may do so.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Privacy Considerations</span>
The role of PT-EAP is to act as a secure transport for PB-TNC over a
network before the endpoint has been admitted to the network. As a
transport protocol, PT-EAP does not directly utilize or require
direct knowledge of any personally identifiable information (PII).
PT-EAP will typically be used in conjunction with other EAP methods
that provide for the user authentication (if bidirectional
authentication is used), so the user's credentials are not directly
seen by the PT-EAP inner method.
While PT-EAP does not provide cryptographic protection for the PB-TNC
batches, it is designed to operate within an EAP tunnel method that
provides strong authentication, integrity, and confidentiality
services. Therefore, it is important for deployers to leverage these
protections in order to prevent disclosure of PII potentially
contained within PA-TNC or PB-TNC within the PT-EAP payload.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the
PT-EAP protocol, in accordance with <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a> [<a href="./rfc5226" title="">RFC5226</a>].
The EAP Method type for PT-EAP has been assigned value 54, i.e., the
assignment for Type in <a href="#section-3.3">Section 3.3</a>.
+-------+----------------------------+-----------+
| Value | Description | Reference |
+-------+----------------------------+-----------+
| 54 | EAP Method Type for PT-EAP | [<a href="./rfc7171">RFC7171</a>] |
+-------+----------------------------+-----------+
<span class="grey">Cam-Winget & Sangster Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7171">RFC 7171</a> NEA PT-EAP May 2014</span>
This document also defines one new IANA top-level registry: "PT-EAP
Versions". This section explains how this registry works. Because
only eight (8) values are available in this registry, a high bar is
set for new assignments. The only way to register new values in this
registry is through Standards Action (via an approved Standards Track
RFC).
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Registry for PT-EAP Versions</span>
The name for this registry is "PT-EAP Versions". Each entry in this
registry includes a decimal integer value between 1 and 7 identifying
the version and also includes a reference to the RFC where the
version is defined.
The following entries are defined in this document and are the
initial entries in the registry. Additional entries to this registry
are added by Standards Action, as defined in <a href="./rfc5226">RFC 5226</a> [<a href="./rfc5226" title="">RFC5226</a>].
+-------+------------------------+
| Value | Defining Specification |
+-------+------------------------+
| 0 | Reserved |
| 1 | [<a href="./rfc7171">RFC7171</a>] |
+-------+------------------------+
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgements</span>
Thanks to the Trusted Computing Group for contributing the initial
text upon which this document was based.
The authors of this document would like to acknowledge the following
people who have contributed to or provided substantial input on the
preparation of this document or predecessors to it: Amit Agarwal,
Morteza Ansari, Diana Arroyo, Stuart Bailey, Boris Balacheff, Uri
Blumenthal, Gene Chang, Scott Cochrane, Pasi Eronen, Aman Garg,
Sandilya Garimella, David Grawrock, Stephen Hanna, Thomas Hardjono,
Chris Hessing, Ryan Hurst, Hidenobu Ito, John Jerrim, Meenakshi
Kaushik, Greg Kazmierczak, Scott Kelly, Bryan Kingsford, PJ Kirner,
Sung Lee, Lisa Lorenzin, Mahalingam Mani, Bipin Mistry, Seiji
Munetoh, Rod Murchison, Barbara Nelson, Kazuaki Nimura, Ron Pon, Ivan
Pulleyn, Alex Romanyuk, Ravi Sahita, Joseph Salowey, Chris Salter,
Mauricio Sanchez, Dean Sheffield, Curtis Simonson, Jeff Six, Ned
Smith, Michelle Sommerstad, Joseph Tardo, Lee Terrell, Susan Thomson,
Chris Trytten, and John Vollbrecht.
<span class="grey">Cam-Winget & Sangster Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7171">RFC 7171</a> NEA PT-EAP May 2014</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC3748">RFC3748</a>] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", <a href="./rfc3748">RFC</a>
<a href="./rfc3748">3748</a>, June 2004.
[<a id="ref-RFC5209">RFC5209</a>] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", <a href="./rfc5209">RFC 5209</a>, June 2008.
[<a id="ref-RFC5226">RFC5226</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
May 2008.
[<a id="ref-RFC5246">RFC5246</a>] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", <a href="./rfc5246">RFC 5246</a>, August 2008.
[<a id="ref-RFC5792">RFC5792</a>] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute
(PA) Protocol Compatible with Trusted Network Connect
(TNC)", <a href="./rfc5792">RFC 5792</a>, March 2010.
[<a id="ref-RFC5793">RFC5793</a>] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC:
A Posture Broker (PB) Protocol Compatible with Trusted
Network Connect (TNC)", <a href="./rfc5793">RFC 5793</a>, March 2010.
[<a id="ref-RFC5929">RFC5929</a>] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", <a href="./rfc5929">RFC 5929</a>, July 2010.
[<a id="ref-RFC7170">RFC7170</a>] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
"Tunnel Extensible Authentication Protocol (TEAP) Version
1", <a href="./rfc7170">RFC 7170</a>, May 2014.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-Asokan">Asokan</a>] Asokan, N., Niemi, V., Nyberg, K., and Nokia Research
Center, Finland, "Man-in-the-Middle Attacks in Tunneled
Authentication Protocols", Nov 2002,
<<a href="http://eprint.iacr.org/2002/163.pdf">http://eprint.iacr.org/2002/163.pdf</a>>.
[<a id="ref-RFC4851">RFC4851</a>] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST)", <a href="./rfc4851">RFC 4851</a>, May
2007.
<span class="grey">Cam-Winget & Sangster Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc7171">RFC 7171</a> NEA PT-EAP May 2014</span>
[<a id="ref-RFC5281">RFC5281</a>] Funk, P. and S. Blake-Wilson, "Extensible Authentication
Protocol Tunneled Transport Layer Security Authenticated
Protocol Version 0 (EAP-TTLSv0)", <a href="./rfc5281">RFC 5281</a>, August 2008.
[<a id="ref-RFC6813">RFC6813</a>] Salowey, J. and S. Hanna, "The Network Endpoint Assessment
(NEA) Asokan Attack Analysis", <a href="./rfc6813">RFC 6813</a>, December 2012.
[<a id="ref-RFC6876">RFC6876</a>] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture
Transport Protocol over TLS (PT-TLS)", <a href="./rfc6876">RFC 6876</a>, February
2013.
Authors' Addresses
Nancy Cam-Winget
Cisco Systems
80 West Tasman Drive
San Jose, CA 95134
US
EMail: ncamwing@cisco.com
Paul Sangster
Symantec Corporation
6825 Citrine Drive
Carlsbad, CA 92009
US
EMail: paul_sangster@symantec.com
Cam-Winget & Sangster Standards Track [Page 19]
</pre>
|
