-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathREST-GSS.html
1372 lines (1284 loc) · 80.2 KB
/
REST-GSS.html
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>RESTful Hypertext Transfer Protocol Application-Layer Authentication Using Generic Security Services</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="RESTful Hypertext Transfer Protocol Application-Layer Authentication Using Generic Security Services">
<meta name="keywords" content="Internet-Draft">
<meta name="generator" content="xml2rfc v1.36 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">NETWORK WORKING GROUP</td><td class="header">N. Williams</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">Cryptonector</td></tr>
<tr><td class="header">Intended status: Standards Track</td><td class="header">June 2, 2012</td></tr>
<tr><td class="header">Expires: December 4, 2012</td><td class="header"> </td></tr>
</table></td></tr></table>
<h1><br />RESTful Hypertext Transfer Protocol Application-Layer Authentication Using Generic Security Services<br />draft-williams-rest-gss-01</h1>
<h3>Abstract</h3>
<p>This document describes a method for application-layer
authentication in Hypertext Transfer Protocol (HTTP)
applications using Generic Security Services Application
Programming Interface (GSS-API) mechanisms via, for simplicity,
the Simple Authentication and Security Layers (SASL) mechanism
bridge known as "GS2". This approach to authentication allows
for pluggability, mutual authentication, and channel binding,
all with no changes to HTTP nor the Transport Layer
Security (TLS).
</p>
<p>We hope that the use of mutual authentication and channel
binding at the application layer will make phishing more
difficult. We hope that the use of authentication at the
application layer will make REST-GSS deployable.
</p>
<h3>Status of this Memo</h3>
<p>
This Internet-Draft is submitted in full
conformance with the provisions of BCP 78 and BCP 79.</p>
<p>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p>
<p>
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to cite
them other than as “work in progress.”</p>
<p>
This Internet-Draft will expire on December 4, 2012.</p>
<h3>Copyright Notice</h3>
<p>
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.</p>
<p>
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) 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.</p>
<p>
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.</p>
<a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>
Introduction<br />
<a href="#anchor2">1.1.</a>
On Application-Layer Authentication Services<br />
<a href="#anchor3">1.2.</a>
Conventions used in this document<br />
<a href="#anchor4">1.3.</a>
GSS-API and SASL Primer<br />
<a href="#anchor5">1.4.</a>
Channel Binding Primer<br />
<a href="#anchor6">1.5.</a>
Glossary<br />
<a href="#anchor7">2.</a>
The Protocol<br />
<a href="#anchor8">2.1.</a>
Authentication Message Format<br />
<a href="#anchor9">2.1.1.</a>
ABNF for Initial Authentication Message Header<br />
<a href="#anchor10">2.2.</a>
Authentication State Cookies<br />
<a href="#anchor11">2.3.</a>
Target Service Naming<br />
<a href="#anchor12">2.4.</a>
Authorization ID Form<br />
<a href="#anchor13">2.5.</a>
Mechanism, Channel Binding Type, and Other Negotiation<br />
<a href="#anchor14">2.6.</a>
Session Status Representation<br />
<a href="#anchor15">2.7.</a>
Session Binding via MIC Tokens<br />
<a href="#anchor16">2.8.</a>
Alternative Session Binding Options<br />
<a href="#anchor17">2.9.</a>
Server Indication of Authentication Requirement<br />
<a href="#anchor18">3.</a>
Examples<br />
<a href="#anchor19">3.1.</a>
Server Decides When to Authenticate<br />
<a href="#anchor20">3.2.</a>
Mechanism and Other Negotiation<br />
<a href="#anchor21">3.3.</a>
Login, Session, and Logout, with SCRAM<br />
<a href="#anchor22">4.</a>
Implementation and Deployment Considerations<br />
<a href="#anchor23">4.1.</a>
Desired GSS-API Extensions<br />
<a href="#anchor24">5.</a>
IANA Considerations<br />
<a href="#anchor25">6.</a>
Security Considerations<br />
<a href="#anchor26">6.1.</a>
User Interface and Scripting Interface Recommendations<br />
<a href="#anchor27">6.2.</a>
Platform Integration<br />
<a href="#anchor28">6.3.</a>
Anti-Phishing<br />
<a href="#rfc.references1">7.</a>
References<br />
<a href="#rfc.references1">7.1.</a>
Normative References<br />
<a href="#rfc.references2">7.2.</a>
Informative References<br />
<a href="#rfc.authors">§</a>
Author's Address<br />
</p>
<br clear="all" />
<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
Introduction</h3>
<p>Hypertext transfer Protocol (HTTP) <a class='info' href='#RFC2616'>[RFC2616]<span> (</span><span class='info'>Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.</span><span>)</span></a>
applications often require authentication and related security
services. These applications have a plethora of odd choices for
authentication functioning at various different network layers.
For example: Transport Layer Security (TLS) <a class='info' href='#RFC5246'>[RFC5246]<span> (</span><span class='info'>Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.</span><span>)</span></a> with pre-shared secret keys (PSK), TLS with
user certificates <a class='info' href='#RFC5280'>[RFC5280]<span> (</span><span class='info'>Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.</span><span>)</span></a>, HTTP Basic and
Digest authentication, HTTP/Negotiate, posting of HTML forms
with usernames and passwords filled in, and various methods
based on passing tokens via HTTP redirection, such as OAuth and
OpenID [add references].
</p>
<p>All the authentication methods currently available to HTTP
applications leave something to be desired. For example these
authentication methods operate at various different network
layers, making abstraction of security services particularly
difficult. Another problem is the lack of a secure method of
tying all of a logged-in session's HTTP requests and responses
to the session, with most browser-based applications using
"cookies".
</p>
<p>We propose an alternative method of authentication that
operates at the application layer, and which provides
applications with access to a large number of actual security
mechanisms. This method is based on an exchange of
authentication messages via HTTP POST to either a well-known URI
or to a URI indicated by the server or agreed a priori. These
authentication messages are mostly those of mechanisms defined
for the GSS-API <a class='info' href='#RFC2743'>[RFC2743]<span> (</span><span class='info'>Linn, J., “Generic Security Service Application Program Interface Version 2, Update 1,” January 2000.</span><span>)</span></a>. Channel binding <a class='info' href='#RFC5056'>[RFC5056]<span> (</span><span class='info'>Williams, N., “On the Use of Channel Bindings to Secure Channels,” November 2007.</span><span>)</span></a> is used to bind authentication to TLS
channels. Sessions are referenced via a session URI that is
indicated and authenticated in all requests for a session.
</p>
<p>The appeal of this solution is that a) it is build on
off-the-shelf technologies, b) requiring no modifications to
either HTTP nor TLS, c) that puts the application in control of
authentication, and d) is pluggable, all the while improving
security for HTTP applications whenever GSS mechanisms are used
that provide mutual authentication.
</p>
<p>The GSS-API, and through the "GS2" mechanism bridge, Simple
Authentication and Security Layers (SASL), enjoys a large and
growing number of security mechanisms, such as Kerberos V5 <a class='info' href='#RFC4121'>[RFC4121]<span> (</span><span class='info'>Zhu, L., Jaganathan, K., and S. Hartman, “The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2,” July 2005.</span><span>)</span></a>, SCRAM <a class='info' href='#RFC5802'>[RFC5802]<span> (</span><span class='info'>Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, “Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms,” July 2010.</span><span>)</span></a>, as well as a PKI-based mechanism [Add
reference to PKU2U], mechanisms based on OAuth <a class='info' href='#RFC5849'>[RFC5849]<span> (</span><span class='info'>Hammer-Lahav, E., “The OAuth 1.0 Protocol,” April 2010.</span><span>)</span></a>, OpenID <a class='info' href='#I-D.ietf-kitten-sasl-openid'>[I‑D.ietf‑kitten‑sasl‑openid]<span> (</span><span class='info'>Lear, E., Tschofenig, H., Mauldin, H., and S. Josefsson, “A SASL & GSS-API Mechanism for OpenID,” February 2012.</span><span>)</span></a>, SAML <a class='info' href='#I-D.ietf-kitten-sasl-saml'>[I‑D.ietf‑kitten‑sasl‑saml]<span> (</span><span class='info'>Wierenga, K., Lear, E., and S. Josefsson, “A SASL and GSS-API Mechanism for SAML,” February 2012.</span><span>)</span></a>, and EAP <a class='info' href='#I-D.ietf-abfab-gss-eap'>[I‑D.ietf‑abfab‑gss‑eap]<span> (</span><span class='info'>Hartman, S. and J. Howlett, “A GSS-API Mechanism for the Extensible Authentication Protocol,” May 2012.</span><span>)</span></a>, as well as various legacy
mechanisms such as NTLM [add reference] and a Diffie-Hellman
mechanism [add reference].
</p>
<p>Much of this document assumes some reader familiarity with the
GSS-API and SASL. To aid readers new to the GSS-API we provide
a GSS primer section, below.
</p>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.1"></a><h3>1.1.
On Application-Layer Authentication Services</h3>
<p>The application layer is generally the most convenient for
running authentication services that applications require. On
the other hand, lower network layers have usually been more
convenient for implementing transport security. As a result
many existing Internet applications provide for both, but
historically with no binding between authentication and
transport security, and often providing two transport security
options: one at the application layer, and one below. [Add a
list of representative SASL and GSS-API apps and references,
such as IMAP, POP3, SMTP/SUBMIT, LDAP, DNS (GSS-TSIG), FTP,
SSHv2, etcetera].
</p>
<p>The main disadvantage of application-layer authentication has
been that until recently many applications had to provide
options for two different "security layers": TLS (below the
application layer) and SASL (at the application layer), and
sometimes both might be used at the same time without any
binding between them. The advent of standards for channel
binding <a class='info' href='#RFC5056'>[RFC5056]<span> (</span><span class='info'>Williams, N., “On the Use of Channel Bindings to Secure Channels,” November 2007.</span><span>)</span></a> <a class='info' href='#RFC5929'>[RFC5929]<span> (</span><span class='info'>Altman, J., Williams, N., and L. Zhu, “Channel Bindings for TLS,” July 2010.</span><span>)</span></a>
makes the combination of application-layer authentication with
transport security at lower layers realistic. Therefore we
may now consider solutions that we might once not have.
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.2"></a><h3>1.2.
Conventions used in this document</h3>
<p>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 class='info' href='#RFC2119'>[RFC2119]<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> .
</p>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.3"></a><h3>1.3.
GSS-API and SASL Primer</h3>
<p>The GSS-API and SASL are both simple security frameworks
providing pluggable authentication services and transport
protection facilities to applications. By "pluggable" we mean
that multiple "security mechanisms" may be used by
applications without requiring different specifications for
how the applications use each security mechanism. Moreover,
application programming interfaces (APIs) for GSS and SASL can
also be pluggable, requiring no changes to applications in
order for them to use new mechanisms.
</p>
<p>A "security mechanism" is an authentication protocol that
conforms to the requirements of the framework in which it
fits, and it provides the requisite authentication
facilities. There are many examples of security mechanisms
[add some].
</p>
<p>The two frameworks are sufficiently similar to each other
that a "bridge" has been added such that all GSS mechanisms
may be used as SASL mechanisms as well. This bridge is known
as "GS2" <a class='info' href='#RFC5801'>[RFC5801]<span> (</span><span class='info'>Josefsson, S. and N. Williams, “Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family,” July 2010.</span><span>)</span></a>. For the remainder of this
section we'll describe SASL only as it works with only GS2
mechanisms.
</p>
<p>Authentication proceeds by having a client ("initiator", in
GSS terminology) send an initial authentication message
("security context token", in GSS terminology). The server
("acceptor") consumes said token and produces one of three
results -success, failure, or "continue needed"-, as well as,
possibly, a message to return to the client. The security
mechanism may require an arbitrary number of security context
tokens be exchanged, always in a synchronous fashion, until
ultimate success or failure. Upon success the peers are said
to have a fully-established security context, which may then
be used to provide security services such as encryption.
</p>
<p>In SASL the server may be the one to initiate the
authentication message exchange, but, when using GSS mechanisms
via the GS2 bridge it will always be the client that initiates
the exchange. SASL also requires that the application define
an "outcome of authentication message", which is distinct from
any such message that the mechanism may provide.
</p>
<p>Both frameworks allow mechanisms to provide facilities for
application data transport protection -- "security layers", in
SASL terminology. SASL's security layers are stream oriented
(requiring ordered delivery), while GSS' are message oriented
(allowing out-of-order delivery), and thus the GSS-API's
security layers facilities are the more general ones. The
GSS-API provides two methods of protecting application data:
"wrap tokens" and "message integrity check (MIC) tokens".
Wrap tokens bear application data within them, while MIC
tokens do not. Thus wrap tokens may provide encryption
("confidentiality protection"), while MIC tokens only provide
integrity protection. MIC tokens are very similar to HMAC --
readers should think of HMAC output with a header affixed to
both, the HMAC output and the input.
</p>
<p>The GSS-API also provides a keyed pseudo-random function
(PRF) <a class='info' href='#RFC4401'>[RFC4401]<span> (</span><span class='info'>Williams, N., “A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API),” February 2006.</span><span>)</span></a> for keying any application's
non-standard security layers, if any.
</p>
<p>SASL application protocols almost all have an option to use
TLS, therefore SASL's security layers are now eschewed in
favor of using TLS (with channel binding -- see below). Not
all GSS-API application have an option to use a separate
system for transport security, thus GSS applications continue
to use the GSS-API's transport security facilities.
</p>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.4"></a><h3>1.4.
Channel Binding Primer</h3>
<p>Channel binding is a method for composing two or more
end-to-end security facilities such that one facility is
used to show that the end-points of the other are logically
the same as those of the first. This allows applications to
perform authentication at the application layer while
leaving transport protection to a lower layer (e.g., TLS)
without compromising security.
</p>
<p>There are two key aspects to channel binding: a) "channels"
(lower layers) must export "channel bindings data" that are
cryptographically bound to the channel, and b)
authentication mechanisms must be able to consume channel
bindings data to ensure that those channel bindings data are
seen to be the same by both end-points of the authentication
mechanism.
</p>
<p>There exists a specification for TLS channel bindings data:
RFC5929 <a class='info' href='#RFC5929'>[RFC5929]<span> (</span><span class='info'>Altman, J., Williams, N., and L. Zhu, “Channel Bindings for TLS,” July 2010.</span><span>)</span></a>.
</p>
<p>Most GSS-API and SASL/GS2 mechanisms support channel
binding.
</p>
<p>An application that supports a TLS channel for transport
protection, and application-layer authentication-layer
authentication using the GSS-API or SASL/GS2 can perform
channel binding to ensure that the application-layer and
TLS-layer end-points are the same -- that there is no
unauthorized man-in-the-middle (MITM) below the application
layer. (An authorized MITM might be an authorized
proxy.) This is quite simple: first establish a TLS
connection, then extract its channel bindings data, then
initiate GSS or SASL/GS2 authentication using those channel
bindings data as a channel binding input -- if
authentication succeeds, then the TLS channel is bound into
the GSS or SASL/GS2 authentication.
</p>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.5"></a><h3>1.5.
Glossary</h3>
<p>This section is purely INFORMATIVE, being intended to inform
readers who are not familiar with SASL and the GSS-API.
Implementors should refer to the relevant RFCs.
</p>
<p>
</p>
<blockquote class="text"><dl>
<dt>Application protocol</dt>
<dd>The protocol
that is at the top of the protocol stack, such as, for
example, IMAP, LDAP, WebDAV, etcetera [Add lots of
references].
</dd>
<dt>Authentication</dt>
<dd>A process by which one
or more parties are identify themselves and prove (for
some value of "prove") their identities to other
parties.
</dd>
<dt>Authentication message</dt>
<dd>In SASL this
this refers to an opaque message to be exchanged during
authentication and which should carry authentication
information, possibly (likely) cryptographic in nature.
</dd>
<dt>Channel</dt>
<dd>A security facility providing
secure, end-to-end transport of application data. For
example: TLS.
</dd>
<dt>Channel binding</dt>
<dd>A method of ensuring
that the logical end-points of one secure channel are the
same as those of another channel at a lower network
layer.
</dd>
<dt>GS2</dt>
<dd>An adaptation of GSS-API
mechanisms to SASL. As SASL originally had such an
adaptation, we now term that original adaptation "GS1" and
the new adaptation is "GS2". GS2 is significantly simpler
than GS1, provides channel binding (whereas GS1 did not),
and requires one fewer round-trip for its authentication
message exchange than GS1 does. GS2's simplicity stems
from replacing a binary header required by the GSS-API
with a text header, as well as not requring the use of any
per-message tokens.
</dd>
<dt>GSS</dt>
<dd>Generic Security Services. An
abstraction around security mechanisms involving two
entities (a client and a server, effectively, though a
mechanism is allowed to use trusted third parties).
</dd>
<dt>MIC token</dt>
<dd>Message Integrity Check. A
per-message token providing integrity protection to
application data. A MIC token does not carry application
data within it. See also per-message tokens.
</dd>
<dt>Outcome of authentication
message</dt>
<dd>SASL requires that applications define,
for themselves, a message known as the "outcome of
authentication message", which should carry at least a bit
of information indicating whether authentication succeeded
or failed. This is distinct from any such outcome of
authentication messages in security mechanisms (which the
GSS-API effectively requires, at least for authentication
success) in that it also indicates success of
authorization of the authenticated client entity to the
requested authorization ID (if any) on the target
service.
</dd>
<dt>Per-message tokens</dt>
<dd>An octet string
("token") emitted, and consumed, by the GSS-API, and
bearing or authenticating application data, with
cryptographic integrity protection and, optionally,
confidentiality protection. There are two types of
per-message tokens: MIC tokens, and wrap tokens, only the
latter of which bears application data. Per-message
tokens may include headers with data, with cryptographic
integrity protection and, optionally, confidentiality
protection.
</dd>
<dt>SASL</dt>
<dd>Simple Authenication and
Security Layers (SASL) is a framework for authentication
and transport security for applications. SASL supports
many security mechanisms, including all GSS mechanisms via
the "GS2" bridge.
</dd>
<dt>Security mechanism</dt>
<dd>A security
mechanism is a protocol that defines an authentication
message (or "security context token") exchange for
authenticating one or two principals (a client and a
server). A security mechanism may also provide for key
exchange and transport security facilities. Examples
include [list some].
</dd>
<dt>Security context</dt>
<dd>A security context
is the shared secret session keys and authenticated peer
names that results from an authentication message exchange
between two parties.
</dd>
<dt>Security context token</dt>
<dd>An opaque
octet string that is to be sent by the application to a
peer as part of the act of authentication and security
context establishment. See also authentication
message.
</dd>
<dt>Wrap token</dt>
<dd>A wrap token is a
per-message token that bears application data, providing
integrity protection to it, and possibly confidentiality
protection as well. See also per-message tokens.
</dd>
</dl></blockquote><p>
</p>
<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
The Protocol</h3>
<p>At some point the client application determines that REST-GSS
authentication is required. How the client does this is
discussed in a sub-section below, but for the purposes of this
discussion, the client MUST learn or know a URI that will be
used to initiate REST-GSS authentication. Once the client knows
that REST-GSS authentication is required the client begins by
constructing an initial message as described below, then it
POSTs it to the agreed-upon URI.
</p>
<p>The server SHOULD respond to initial authentication messages
with either an error or a 201 response. If there is no error
and there is a response authentication message, it will be
returned to the client as the representation of the resource
created and named in the 201 response, otherwise, if there is no
error then the new resource will have an empty representation.
The new resource name shall be the name of the REST-GSS session,
known as the 'session URI'.
</p>
<p>For security mechanisms that require multiple round-trips then
additional messages from the client SHALL be POSTed to the
session URI, and any response messages from the server will be
returned in 200 results as the new representation of the session
resource.
</p>
<p>The server generally responds to all POSTs to the REST-GSS
login and session URIs with a 201 or a 200 status, respectively.
Failure is signalled by the authentication messages described
below.
</p>
<p>Any GETs of a valid session URI SHALL return a representation of
the status of that session, else the response to the GET SHALL
be an error.
</p>
<p>A DELETE of the session URI logs the session out.
</p>
<p>The requests and responses that make up a session are tied to the
session via the session URI, which is sent in a header. The
requests and responses that make up a session SHOULD be
authenticated by a Message Integrity Check (MIC) token taken
over inputs such that the request or response is bound to the
session.
</p>
<a name="anchor8"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.1"></a><h3>2.1.
Authentication Message Format</h3>
<p>The authentication messages from clients to servers SHALL be
formed as per SASL's <a class='info' href='#RFC4422'>[RFC4422]<span> (</span><span class='info'>Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” June 2006.</span><span>)</span></a> GSS-API bridge
(known as "GS2") <a class='info' href='#RFC5801'>[RFC5801]<span> (</span><span class='info'>Josefsson, S. and N. Williams, “Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family,” July 2010.</span><span>)</span></a>, with the initial
authentication message prefixed with a text header indicating
what options were selected. The reason for this is simple:
implementors who lack a GSS-API implementation will find it
simpler to implement certain mechanisms if the GS2 framework
is used.
</p>
<p>The authentication messages from servers to clients SHALL be
formed SASL GS2 authentication messages pre-fixed with a
header indicating authentication status. The header consists
of a single byte: an ASCII character 'S' (success), 'F'
(failure), or 'C' (the server expects more authentication
messages from the client), followed by an ASCII newline.
</p>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.1.1"></a><h3>2.1.1.
ABNF for Initial Authentication Message Header</h3>
<p>As described above, the initial authentication message from
the client to the server must include a small text header
described by the following Augmented Backus-Naur Form (ABNF)
<a class='info' href='#RFC5234'>[RFC5234]<span> (</span><span class='info'>Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.</span><span>)</span></a>:
</p>
<p>[Add ABNF for a header consisting of a) the selected
SASL/GS2 mechanism name, b) the name of the channel
binding type selected, c) the session protection options
selected, d) room for extensions. -Nico]
</p>
<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.2"></a><h3>2.2.
Authentication State Cookies</h3>
<p>REST-GSS application server implementations must build and
preserve authentication state via a "GSS security context".
Clients must identify such state in the case of security
mechanisms that require multiple authentication message round
trips. The REST-GSS session URI may suffice for this
purpose.
</p>
<p>Such state might, for example consist of a timestamp and a
partially-established security context handle. Some
implementations might serialize partially-established security
contexts and store them somewhere, including on the client.
The timestamp would be used for expiring old
partially-established security contexts. The GSS-API allows
for serializing security contexts into something known as a
"exported security context token". Some GSS-API
implementations allow for exporting partially-established
security contexts.
</p>
<p>Some servers may benefit from being able to store such
authentication state temporarily on the client -- such servers
MAY assign, in every authentication response message when the
server expects additional authentication messages from the
client. Such cookies, if present, MUST be base64-encoded and
MUST be set in a REST-GSS-AuthenCookie response field, and the
client MUST echo such a cookie, if present, in the next
authentication message.
</p>
<p>Note that serialization of partially-established security
contexts is currently not a standard feature of the GSS-API,
but it is available in some implementations. Servers that
lack this feature may need to preserve authentication state in
the form of an identifier for a process that holds the GSS-API
security context, and an opaque security context handle, and
then they must route all subsequent authentication messages
through that process.
</p>
<a name="anchor11"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.3"></a><h3>2.3.
Target Service Naming</h3>
<p>When mutual authentication facilities are available the
client SHOULD set the target acceptor (service) name to be a
GSS-API name of GSS_C_NT_HOSTBASED_SERVICE, with the hostname
portion of the name being the name of the host to which the
client is authenticating. The service name SHOULD be set
as required by the application, or, if not specified, then to
"HTTP". For example, "[email protected]".
</p>
<p>[It'd be good to explore a form of domain-based service
naming without host naming. Thus one could login to a large
site without having to login to each of many services hosted
by different hosts in the same domain. -Nico]
</p>
<a name="anchor12"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.4"></a><h3>2.4.
Authorization ID Form</h3>
<p>The form of the authorization ID, if any is supported, SHALL
be specified by the application. Applications that make no
use of the authorization ID SHOULD reject authentication
attempts requesting any non-empty authorization ID.
</p>
<p>Applications that intend to use the SASL authorization ID
feature should specify a method of preparing the
authorization ID, such as SASLprep <a class='info' href='#RFC4013'>[RFC4013]<span> (</span><span class='info'>Zeilenga, K., “SASLprep: Stringprep Profile for User Names and Passwords,” February 2005.</span><span>)</span></a>.
</p>
<a name="anchor13"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.5"></a><h3>2.5.
Mechanism, Channel Binding Type, and Other Negotiation</h3>
<p>The representation returned by a GET of the resource to which
initial authentication messages are POSTed MUST be as follows:
</p>
<ul class="text">
<li>[Add ABNF for a field/value list with fields for:
<ul class="text">
<li>SASL/GS2 mechanism list;
</li>
<li>supported channel binding type list;
</li>
<li>an indication of what session security facility the
server prefers (cookies or MICs, and if MICs, whether
TLS must always be used and, if not, whether the body
of requests and responses should be protected by the
MICs);
</li>
<li>an indication of whether replay protection is
required by the server, in which case MIC tokens MUST
be used, and they MUST be taken over data that
includes Request-Date and Request-Nanoseconds header
fields.]
</li>
</ul>
</li>
</ul><p>
</p>
<p>Clients that don't know a priori what mechanism, channel
binding type, or session protection method to use, MUST GET
this resource prior to initiatin authentication.
</p>
<p>If a channel binding type list is not advertised by the
server then the client SHOULD pick a channel binding type as
agreed a priori. Applications must specify any pre-agreed
channel binding type selection criteria.
</p>
<p>In any case of ambiguity or failure to specify, the client
SHOULD pick the tls-server-end-point channel binding type
<a class='info' href='#RFC5929'>[RFC5929]<span> (</span><span class='info'>Altman, J., Williams, N., and L. Zhu, “Channel Bindings for TLS,” July 2010.</span><span>)</span></a> if a server certificate was used to
authenticate the server end-point of the TLS channel, else the
client SHOULD pick tls-unique.
</p>
<a name="anchor14"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.6"></a><h3>2.6.
Session Status Representation</h3>
<p>The status of a session SHALL be obtained by a GET of the
session URI. The status of a session SHALL consist of:
</p>
<ul class="text">
<li>[Add an ABNF for a field/value list with the following
elements:
<ul class="text">
<li>a boolean to indicate whether the session is fully
established;
</li>
<li>a timestamp indicating hard expiration, if any;
</li>
<li>a relative time specification indicating what the
session idle timer, if any, is;
</li>
<li>possibly some items indicating authorization
attributes of the client, such as the SASL
authorization ID selected or accepted by the server,
if any.]
</li>
</ul>
</li>
</ul><p>
</p>
<a name="anchor15"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.7"></a><h3>2.7.
Session Binding via MIC Tokens</h3>
<p>MIC tokens are used to bind HTTP requests and responses to
containing sessions. Requests (and their responses) can be
bound to more than one session for session combination
purposes.
</p>
<p>[A word about MIC tokens: they are quite similar to HMAC
<a class='info' href='#RFC2104'>[RFC2104]<span> (</span><span class='info'>Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” February 1997.</span><span>)</span></a>. For simple GSS-API mechanisms they
might be nothing more than an HMAC, with, perhaps a header
affixed to the application data that the MIC is applied
to.]
</p>
<p>MIC tokens for requests are generated by applying
GSS_Get_MIC() to a a minimized form of the request
containing only the following items:
</p>
<ul class="text">
<li>the request start line;
</li>
<li>the Host header field, if any;
</li>
<li>optionally a Request-Date field with the same value form
as the 'Date' field (this field MUST be sent in the
request as well if present in the MIC input);
</li>
<li>optionally a Request-Nanoseconds field bearing a
nanoseconds component of the time at which the request was
made, as an unsigned integer in decimal, ASCII
respresentation (e.g., 1234567) (this field MUST be sent
in the request as well if present in the MIC input);
</li>
<li>a Channel-Binding field bearing the channel bindings data
(base64-encoded) of the channel over which the message is
being sent (note: the channel bindings should be prefixed
with the channel binding type as described in RFC5056, and
prior to base64 encoding)), if there is a channel (this
field MUST NOT be included in the request);
</li>
<li>the request body if and only if there is no channel to
bind to, else an empty request body.
</li>
</ul><p>
</p>
<p>The request MIC is base64-encoded, prefixed with the session
URI (separated by an ASCII semi-colon) and placed in a header
field named REST-GSS-Request-MIC. Multiple MICs may be placed
in this field, separated by whitespace. [XXX Add ABNF for
this! Also, add an indication of what CB type is used in the
request MIC token.]
</p>
<p>The optional timestamp in the request SHOULD be used for
replay detection on the server side. GSS-API per-message
token replay detection facilities exist, but an implementation
may not make it easier to share a security context's replay
state easily across multiple processes or even servers in a
cluster.
</p>
<p>MIC tokens for responses are generated by applying
GSS_Get_MIC() to a a minimized form of the response
containing only the following items:
</p>
<ul class="text">
<li>the request status line;
</li>
<li>the REST-GSS-Request-MIC from the request, with runs of
whitespace characters replaced with a single ASCII
space.
</li>
<li>the response body if and only if there is no channel to
bind to, else an empty response body.
</li>
</ul><p>
</p>
<p>The response MIC is base64-encoded, prefixed with the session
URI (separated by an ASCII semi-colon) and placed in a header
field named REST-GSS-Response-MIC. Multiple MICs may be placed
in this field, separated by whitespace.
</p>
<p>These MIC tokens are validated by calling GSS_Verify_MIC()
with the same input data as GSS_Get_MIC().
</p>
<a name="anchor16"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.8"></a><h3>2.8.
Alternative Session Binding Options</h3>
<p>[Add text describing the use of cookies instead of MIC
tokens.]
</p>
<p>[Add text describing a method of associating REST-GSS session
URIs with TLS session IDs instead of using MIC tokens on every
request/response. This is only workable when the client's and
server's HTTP/TLS stacks expose enough information to the
application.]
</p>
<a name="anchor17"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.9"></a><h3>2.9.
Server Indication of Authentication Requirement</h3>
<p>When the server wishes to indicate that the client must
authenticate in order to access a given resource, then the
server MUST respond to the client's HTTP request with either
a redirection to a web page with a 303 redirect to a login
page (this in the case of browser applications) or a
TBD 4xx error indicating that access requires REST-GSS login
and, optionally directing the client to the REST-GSS login URI
by listing that URI in a response header field named
'REST-GSS-Authenticate'.
</p>
<a name="anchor18"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.
Examples</h3>
<a name="anchor19"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.1"></a><h3>3.1.
Server Decides When to Authenticate</h3>
<br /><hr class="insert" />
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
C->S: HTTP/1.1 GET /some/resource
Host: A.example
S->C: HTTP/1.1 303 http://A.example/login.html&<encoded-URI>
</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Authentication required indication browser apps </b></font><br /></td></tr></table><hr class="insert" />
<br /><hr class="insert" />
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>