-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathgss-browserid.xml
1624 lines (1621 loc) · 83.7 KB
/
gss-browserid.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc tocindent="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc tocindent="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2743 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2743.xml">
<!ENTITY RFC3961 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3961.xml">
<!ENTITY RFC4402 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4402.xml">
<!ENTITY RFC4121 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4121.xml">
<!ENTITY RFC4178 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4178.xml">
<!ENTITY RFC4422 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4422.xml">
<!ENTITY RFC4556 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4556.xml">
<!ENTITY RFC4757 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4757.xml">
<!ENTITY RFC4985 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4985.xml">
<!ENTITY RFC5178 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5178.xml">
<!ENTITY RFC5280 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC5801 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5801.xml">
<!ENTITY RFC5929 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5929.xml">
<!ENTITY RFC6680 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6680.xml">
<!ENTITY JWA PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-jose-json-web-algorithms.xml">
<!ENTITY JWK PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-jose-json-web-key.xml">
<!ENTITY JWS PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-jose-json-web-signature.xml">
<!ENTITY JWT PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-json-web-token.xml">
<!ENTITY NegoEx PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zhu-negoex.xml">
<!ENTITY PKU2U PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zhu-pku2u.xml">
<!ENTITY RFC4120 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml">
]>
<rfc docName="draft-howard-gss-browserid-07.txt" ipr="trust200902" category="exp" updates="">
<front>
<title abbrev="BrowserID SASL & GSS-API">A SASL and GSS-API Mechanism for the BrowserID Authentication Protocol</title>
<author initials="L." surname="Howard" fullname="Luke Howard">
<organization abbrev="PADL">PADL Software</organization>
<address>
<postal>
<street>PO Box 59</street>
<city>Central Park</city>
<region>VIC</region>
<code>3145</code>
<country>Australia</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author initials="N." surname="Williams" fullname="Nicolas Williams">
<organization abbrev="Cryptonector">Cryptonector, LLC</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date month="December" year="2013"/>
<area>
Security Area
</area>
<keyword>Internet-Draft</keyword>
<abstract>
<t>
This document defines protocols, procedures and conventions for a Generic Security Service Application Program Interface (GSS-API) security mechanism based on the BrowserID authentication mechanism. Through the GS2 family of mechanisms defined in RFC 5801, these protocols also define how Simple Authentication and Security Layer (SASL, RFC 4422) applications may use BrowserID.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="d1e817">
<t><xref target="BrowserID"/> is a web-based three-party security protocol by which user agents can present to a Relying Party (RP) a signed assertion of e-mail address ownership. BrowserID was intended to be used for web authentication. We find BrowserID to be useful in general, therefore we define herein how to use it in many more applications.</t>
<t>
The Simple Authentication and Security Layer (SASL) <xref target="RFC4422"/> is a framework for providing authentication and message protection services via pluggable mechanisms. Protocols that support it include IMAP, SMTP, and XMPP.</t>
<t>
The Generic Security Service Application Program Interface (GSS-API) <xref target="RFC2743"/> provides a framework for authentication and message protection services through a common programming interface. This document conforms to the SASL and GSS-API bridge specified in <xref target="RFC5801"/>, so it defines both a SASL and GSS-API mechanism.</t>
<t>
The BrowserID mechanism described in this document reuses the existing web-based BrowserID protocol, but profiles it for use in applications that support SASL or GSS-API, adding features such as key agreement, mutual authentication, and fast re-authentication.</t>
<t>
The following diagram illustrates the interactions between the three parties in the GSS BrowserID protocol. Note that the terms client, initiator and user agent (UA) are used interchangeably in this document, as are server, acceptor and relying party (RP). </t>
<t>
</t>
<t>
<figure anchor="magicparlabel-175" title="Interworking Architecture">
<artwork>
+------------+
| BrowserID |
| identity |
| provider |
+------------+
// \\
// \\
// \\
// \\
make signed // \\ fetch IdP public
certificate // \\ key over HTTPS
for user's // \\ (RP may cache)
public key // \\
// \\
// \\
// \\
|/ \|
+-------------+ +-------------+
| SASL or GSS | GSS BrowserID | SASL or GSS |
| client/UA |<------------------->| server/RP |
| (initiator) | | (acceptor) |
+-------------+ +-------------+
</artwork>
</figure>
</t>
<section title="Discovery and Negotiation" anchor="d1e885">
<t>
The means of discovering GSS-API peers and their supported mechanisms is out of this specification's scope. They may use SASL <xref target="RFC4422"/> or the Simple and Protected Negotiation mechanism (SPNEGO) <xref target="RFC4178"/>.</t>
<t>
Discovery of a BrowserID identity provider (IdP) for a user is described in the BrowserID specification. A domain publishes a document containing their public key and URIs for authenticating and provisioning users, or pointer to an authority containing such a document.</t>
</section>
<section title="Authentication" anchor="d1e909">
<t>
The GSS-API protocol involves a client, known as the initiator, sending an initial security context token of a chosen GSS-API security mechanism to a peer, known as the acceptor. The two peers subsequently exchange, synchronously, as many security context tokens as necessary to complete the authentication or fail. The specific number of context tokens exchanged varies by security mechanism: in the case of the BrowserID mechanism, it is typically two (i.e. a single round trip), however it can be more in some cases. Once authentication is complete, the initiator and acceptor share a security context which identifies the peers and can optionally be used for integrity or confidentiality protecting subsequent application messages.</t>
<t>
The original BrowserID protocol, as defined outside this document, specifies a bearer token authentication protocol for web applications. The user agent generates a short-term key pair, the public key of which is signed by the user's IdP. (The user must have already authenticated to the IdP; how this is done is not specified by BrowserID, but forms-based authentication is common.) The IdP returns a certificate for the user which may be cached by the user's browser. When authenticating to a Relying Party (RP), the browser generates an identity assertion containing the RP domain and an expiration time. The user agent signs this and presents both the assertion and certificate to the RP. (The combination of an assertion and zero or more certificates is termed a “backed assertion”.) The RP fetches the public key for the IdP, validates the user's certificate (and those of any intermediate certifying parties) and then verifies the assertion.</t>
<t>
The GSS BrowserID protocol extends this by having the RP always send back a response to the user agent, which at a minimum provides key confirmation (this is needed for some key agreement methods) and indicates the lifetime of the established security context. The key confirmation token is also required for mutual authentication, when the initiator application requests that feature.</t>
</section>
<section title="Message protection services" anchor="d1e925">
<t>
GSS-API provides a number of a message protection services:</t>
<t>
<list style="hanging">
<t hangText="GSS_Wrap()">
integrity and optional confidentiality for a message</t>
<t hangText="GSS_GetMIC()">
integrity for a message sent separately</t>
<t hangText="GSS_Pseudo_random()">
shared key derivation (e.g., for keying external confidentiality+integrity layers)</t>
</list>
</t>
<t>
These services may be used with security contexts that have a shared session key, to protect application-layer messages.</t>
</section>
</section>
<section title="Requirements notation" anchor="d1e953">
<t>
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 <xref target="RFC2119"/>.</t>
<t>
The reader is assumed to be familiar with the terms used in the BrowserID specification.</t>
</section>
<section title="Naming" anchor="d1e971">
<t>
The GSS-API provides a rich security principal naming model. At its most basic the query forms of names consist of a user-entered/displayable string and a “name-type”. Name-types are constants with names prefixed with “GSS_C_NT_” in the GSS-API. Names may also have attributes <xref target="RFC6680"/>.</t>
<section title="GSS name types" anchor="d1e986">
<section title="GSS_C_NT_BROWSERID_PRINCIPAL" anchor="sub_GSS_C_NT_BROWSERID_PRINCIPAL">
<t>
This name may contain an e-mail address, or a service principal name identifying an acceptor. The encoding of service principal names is intended to be somewhat compatible with the Kerberos <xref target="RFC4120"/> security protocol (without the realm name).</t>
<t>
The following ABNF defines the 'name' rule that names of this type must match.</t>
<t>
<cref>
Should we reference RFC2822 here? The Mozilla BrowserID docs sure don't.</cref>
</t>
<t>
</t>
<t>
<figure suppress-title="true" align="center">
<artwork> char-normal = %x00-2E/%x30-3F/%x41-5B/%x5D-FF
char-escaped = "\" %x2F / "\" %x40 / "\" %x5C
name-char = char-normal / char-escaped
name-string = 1*name-char
user = name-string
domain = name-string
email = user "@" domain
service-name = name-string
service-host = name-string
service-specific = name-string
service-specifics = service-specific 0*("/" service-specifics)
spn = service-name ["/" service-host [ "/" service-specifics]]
name = email / spn</artwork>
</figure>
</t>
</section>
<section title="GSS_C_NT_USER_NAME" anchor="d1e1022">
<t>
This name is implicitly converted to a GSS_C_NT_BROWSERID_PRINCIPAL. A default domain may be appended when importing names of this type.</t>
</section>
<section title="GSS_C_NT_HOSTBASED_SERVICE" anchor="d1e1031">
<t>
This name is transformed by replacing the “@” symbol with a “/”, and then implicitly converted to a GSS_C_NT_BROWSERID_PRINCIPAL.</t>
</section>
<section title="GSS_C_NT_DOMAINBASED_SERVICE" anchor="d1e1040">
<t><xref target="RFC5178"/> domain-based service names are transformed into a GSS_C_NT_BROWSERID_PRINCIPAL as follows:</t>
<t>
<list style="symbols">
<t>
the <service> name becomes the first component of the BrowserID principal name (service-name in ABNF)</t>
<t>
the <hostname> becomes the second component (service-host)</t>
<t>
the <domain> name becomes the third component (service-specific)</t>
</list>
</t>
</section>
<section title="GSS_C_NT_ANONYMOUS" anchor="d1e1066">
<t>
If the initiator principal's leaf certificate does not contain a “principal” claim, then the initiator name has this name type.</t>
</section>
</section>
<section title="Name canonicalization" anchor="d1e1075">
<t>
The BrowserID GSS-API mechanism performs no name canonicalization. The mechanism's GSS_Canonicalize_name() returns an MN whose display form is the same as the query form. Of course, the principal named obtained from a CREDENTIAL HANDLE may be canonical in that the IdP might only issue credentials for canonical names, but credential acquisition is out of scope here.</t>
</section>
<section title="Exported name token format" anchor="d1e1084">
<t>
The exported name token format for the BrowserID GSS-API mechanism is the same as the query form, plus the standard exported name token format header mandated by the GSS-API <xref target="RFC2743"/>.</t>
<t>
<cref>
Do we wish to say anything about the exported composite name token format? It should be an encoding of the initiator's leaf certificate.</cref>
</t>
</section>
<section title="Naming extensions" anchor="d1e1102">
<t>
The acceptor MAY surface attributes from the assertion and any certificates using GSS_Get_name_attribute() (see <xref target="RFC6680"/>). The URN prefix is "urn:<TBD>:params:gss:jwt". If a SAML assertion is present in the "saml" parameter of the leaf certificate, it may be surfaced using the URN prefix "urn:<TBD>:params:gss:federated-saml-attribute".</t>
<t>
Attributes from the assertion MUST be marked as unauthenticated unless otherwise validated by the acceptor (e.g. the audience).</t>
<t>
Attributes from certificates SHOULD be marked as authenticated.</t>
</section>
</section>
<section title="Context tokens" anchor="d1e1124">
<t>
All context tokens include a two-byte token identifier followed by a backed BrowserID assertion. This document defines the following token IDs:</t>
<texttable>
<ttcol align="center">
Section</ttcol>
<ttcol align="center">
Token ID</ttcol>
<ttcol align="center">
ASCII</ttcol>
<ttcol align="center">
Description</ttcol>
<c>
4.1.1</c>
<c>
0x632C</c>
<c>
c,</c>
<c>
Initiator context token</c>
<c>
4.1.2</c>
<c>
0x432C</c>
<c>
C,</c>
<c>
Acceptor context token</c>
<c>
</c>
<c>
0x442C</c>
<c>
D,</c>
<c>
Context deletion token</c>
<c>
4.2.4</c>
<c>
0x6D2C</c>
<c>
m,</c>
<c>
Initiator metadata token</c>
<c>
4.2.4</c>
<c>
0x4D2C</c>
<c>
M,</c>
<c>
Acceptor metadata token</c>
</texttable>
<t>
The token ID has a human-readable ASCII encoding for the benefit of pure SASL implementations of this mechanism.</t>
<section title="Base protocol" anchor="d1e1276">
<section title="Initial context token" anchor="sub_Initial_context_token">
<t>
The initial context token is framed per Section 1 of <xref target="RFC2743"/>:</t>
<t>
</t>
<t>
<figure suppress-title="true" align="center">
<artwork> GSS-API DEFINITIONS ::=
BEGIN
MechType ::= OBJECT IDENTIFIER
-- representing BrowserID mechanism
GSSAPI-Token ::=
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerToken ANY DEFINED BY thisMech
-- token ID and backed assertion
}
END</artwork>
</figure>
</t>
<t>
Unlike many other GSS-API mechanisms such as Kerberos, this token framing is not used by subsequent context or by <xref target="I-D.zhu-negoex"/> metadata tokens. As such, pure SASL implementations of this mechanism do not need to deal with DER encoding the mechanism object identifier.</t>
<t>
GSS BrowserID is a family of mechanisms, where the last element in the OID arc indicates the <xref target="RFC4121"/> encryption type supported for message protection services. The OID prefix is 1.3.6.1.4.1.5322.24.1. The NULL encryption type is valid, in which case services that require a key are not available.</t>
<t>
The innerToken consists of the initiator context token ID concatenated with a backed assertion for the audience corresponding to the target name passed into GSS_Init_sec_context(). In addition, the assertion MAY contain the additional claims, which are described later in this document:</t>
<t>
<list style="symbols">
<t>
ECDH key agreement parameters (see <xref target="sub_request_ecdh"/>)</t>
<t>
Channel binding information (see <xref target="sub_request_cbt"/>)</t>
<t>
A nonce for binding the request to a response signed with a private key for mutual authentication (see <xref target="sub_request_nonce"/>)</t>
<t>
A ticket identifier for fast re-authentication using an established session key rather than a BrowserID certificate (see <xref target="sub_request_tkt"/>)</t>
</list>
</t>
<t>
The call to GSS_Init_sec_context() returns GSS_C_CONTINUE_NEEDED to indicate that a subsequent context token from the acceptor is expected.</t>
</section>
<section title="Acceptor context token" anchor="sub_Acceptor_context_token">
<t>
Upon receiving a context token from the initiator, the acceptor validates that the token is well formed and contains a valid BrowserID mechanism OID and the initiator context token ID.</t>
<t>
The acceptor then verifies the backed identity assertion per the BrowserID specification. This includes validating the expiry times, audience, certificate chain, and assertion signature. The acceptor then verifies the channel binding token, if present, and any other GSS-specific claims in the assertion. In case of failure, a response assertion containing GSS major and minor status codes SHOULD be returned.</t>
<t>
If the <xref target="RFC3961"/> encryption type for the selected mechanism is not ENCTYPE_NULL, the acceptor generates a ECDH public key using the parameters received from the client (see <xref target="sub_response_ecdh"/>), and from it derives the RP Response Key (RRK) (see <xref target="sub_kd_RRK"/>). The acceptor then generates a response assertion containing its ECDH public key and context expiration time (note that the context expiration time is a purely informational quantity). The response assertion will be:</t>
<t>
<list style="symbols">
<t>
signed in the acceptor's private key, if mutual authentication was requested, and the acceptor has a key (see <xref target="sub_Extensions_for_mutual"/>);</t>
<t>
signed in the RRK, if the encryption type for the selected mechanism is not ENCTYPE_NULL;</t>
<t>
not signed in all other cases.</t>
</list>
</t>
<t>
The response assertion is encoded as a backed assertion, prefixed with the acceptor context token ID. It SHALL have a certificate count of zero.</t>
<t>
Finally, the Context Root Key (CRK) (see <xref target="sub_kd_CRK"/>) is derived from the ECDH shared secret (if present) and GSS_S_COMPLETE is returned, along with the initiator name from the verified assertion. If the CRK is available, the replay_det_state (GSS_C_REPLAY_FLAG), sequence_state (GSS_C_SEQUENCE_FLAG), conf_avail (GSS_C_CONF_FLAG) and integ_avail (GSS_C_INTEG_FLAG) security context flags are set to TRUE.</t>
<t>
Other assertion/certificate claims MAY be made available via GSS_Get_name_attribute().</t>
</section>
<section title="Initiator context completion" anchor="sub_Initiator_context_completion">
<t>
Upon receiving the acceptor context token, the initiator unpacks the response assertion and, if applicable, computes the ECDH shared secret and RRK. The RRK is used to verify the response assertion unless mutual authentication is available, in which case the acceptor's public key will be used.</t>
<t>
The initiator sets the context expiry time with that received in the response assertion, if present; otherwise, the context expires when the initiator principal's certificate expires.</t>
<t>
The CRK is derived from the ECDH shared secret and GSS_S_COMPLETE is returned to indicate the initiator is authenticated and the context is ready for use. No output token is emitted. Security context flags are set as for the acceptor context.</t>
</section>
</section>
<section title="Mutual authentication" anchor="sub_Extensions_for_mutual">
<t>
Mutual authentication allows the acceptor to be authenticated to the initiator. The mechanism SHALL set the mutual_state security context flag (GSS_C_MUTUAL_FLAG) to TRUE if mutual authentication succeeded. Support for mutual authentication is OPTIONAL.</t>
<t>
The base protocol is extended as follows to support this:</t>
<section title="Initiator mutual authentication context token" anchor="d1e1441">
<t>
If the initiator requested the mutual_state flag, it sends in its request assertion an “opts” claim (see <xref target="sub_request_opts"/>) containing the “ma” value. It also includes a nonce (see <xref target="sub_request_nonce"/>) in order to bind the initiator and acceptor assertions.</t>
</section>
<section title="Acceptor mutual authentication context token" anchor="d1e1456">
<t>
If the acceptor has a private key and certificate available and the initiator indicated it desired mutual authentication by including the “ma” protocol option, the acceptor signs the response using a private key rather than the RP Response Key (RRK). The response includes the nonce from the initiator's assertion. The acceptor MUST reject requests for mutual authentication lacking a nonce.</t>
<t>
While the response is a backed assertion, in order to take advantage of existing keying infrastructures BrowserID certificates MUST NOT be included in the backed assertion. Rather, an X.509 certificate SHALL be included as a value for the "x5c" header parameter in the assertion (see <xref target="I-D.ietf-jose-json-web-signature"/> 4.1.6). The certificate MUST be valid for signing.</t>
<t>
<cref>
We don't want to burden the initiator with having to implement both methods of authenticating acceptors, and given that initiators and acceptors both will generally need a PKIX implementation, and given that acceptors will need a PKIX credential for TLS, and that there is as yet no standard protocol for automatic provisioning of BrowserID credentials for servers, using PKIX to authenticate the server seems to be the easiest way to go.</cref>
</t>
</section>
<section title="Initiator mutual authentication context completion" anchor="d1e1478">
<t>
The initiator verifies the assertion signature and that the nonce matches, and validates the certificate chain according to <xref target="RFC5280"/>.</t>
<t>
Initiators MUST authenticate the service name using the matching rules below:</t>
<t>
<list style="symbols">
<t>
A service-name EKU from the registry defined by <xref target="I-D.zhu-pku2u"/>; id-kpServerAuth maps to the “http” service</t>
<t>
A spn expressed as a KRB5PrincipalName in the id-pkinit-san otherName SAN (see <xref target="RFC4556"/> Section 3.2.2; the realm is ignored)</t>
<t>
A service-name expressed as a SRVName SAN (see <xref target="RFC4985"/>)</t>
<t>
Optionally, an out-of-band binding to the certificate</t>
</list>
</t>
<t>
If there are no EKUs, or a single EKU containing id-kp-anyExtendedKeyUsage, and no SAN containing the service name is present, then all service names match. If a SAN containing the service name is present, then any EKUs are ignored.</t>
<t>
If the the host component of the service name (service-host) is not expressed in a SAN as specified above, it MUST be present as a value for the dNSName SAN or as the least significant Common Name RDN. </t>
<t>
Note only the id-pkinit-san or SRVName SANs provide the ability to authenticate the a service name containing a service-specific component.</t>
</section>
<section title="Acceptor certificate advertisement" anchor="sub_NegoEx">
<t><xref target="I-D.zhu-negoex"/> may be used to advertise acceptor certificates.</t>
<t>
If the acceptor supports mutual authentication, it MAY include its certificate and any additional certificates inside a backed assertion with an empty payload as output for GSS_Query_meta_data(). The "assertion" is prefixed with the two byte token identifier “M,”.</t>
<t>
Upon receiving this, the initiator MAY validate the certificate or fingerprint, or present either to the initiator before committing to authenticate.</t>
<t>
The NegoEx signing key is the output of GSS_Pseudo_random() (see <xref target="sub_GSS_PRF"/>) with an input of GSS_C_PRF_KEY_FULL and "gss-browserid-negoex-initiator" or "gss-browserid-negoex-acceptor" (without quotes), depending on the party generating the signature.</t>
<t>
The NegoEx authentication scheme is the binary encoding of the following hexadecimal string:</t>
<t>
535538008647F5BC624BD8076949F0</t>
<t>
where the third byte (zero above) is set to the <xref target="RFC3961"/> encryption type for the selected mechanism. The authentication scheme for encryption types greater than 255 is not specified here.</t>
<t>
There is currently no initiator-sent metadata defined and acceptors should ignore any sent. The metadata is advisory and the initiator is free to ignore it.</t>
<t>
<cref>
Delete this section as NegoEx will likely not be progressed.</cref>
</t>
</section>
</section>
<section title="Fast re-authentication" anchor="sub_Fast_re_authentication">
<t>
Fast re-authentication allows a security context to be established using a secret key derived from the initial certificate-signed ECDH key agreement.</t>
<t>
The re-authentication assertion is signed with a HMAC using the Authenticator Root Key (ARK) (see <xref target="sub_kd_ARK"/>), rather than a initiator principal's BrowserID certificate.</t>
<t>
Support for fast re-authentication is OPTIONAL and is indicated by the acceptor returning a ticket in the response assertion.</t>
<section title="Ticket generation" anchor="d1e1608">
<t>
If the acceptor supports re-authentication, the following steps are added to <xref target="sub_Acceptor_context_token"/>:</t>
<t>
<list style="numbers">
<t>
A unique, opaque ticket identifier is generated.</t>
<t>
The acceptor creates a JSON object containing the ticket identifier and expiry time and returns it in the response to the initiator (see <xref target="sub_response_tkt"/>).</t>
</list>
</t>
<t>
The acceptor must be able to use the ticket identifier to securely retrieve the subject, issuer, audience, expiry time, ARK and any other relevant properties of the original security context. One implementation choice may be to use the ticket identifier as a key into a dictionary containing this information. Another would be to encrypt this information in a long-term secret only known to the acceptor and encode the resulting cipher-text in the opaque ticket identifier.</t>
<t>
The ticket expiry time by default SHOULD match the initiator's certificate expiry, however it MAY be configurable so the ticket expires before or after the certificate.</t>
<t>
The initiator MAY cache tickets, along with the ARK, received from the acceptor in order to re-authenticate to it at a future time.</t>
</section>
<section title="Initiator re-authentication context token" anchor="d1e1639">
<t>
The initiator looks in its ticket cache for an unexpired ticket for the desired acceptor. If none is found, the normal certificate-based authentication flow is performed, otherwise:</t>
<t>
<list style="numbers">
<t>
The initiator generates a re-authentication assertion containing: the name of the acceptor (see <xref target="sub_request_aud"/>), an expiry time (see <xref target="sub_request_exp"/>) and/or the current time (see <xref target="sub_request_iat"/>), optional channel binding information (see <xref target="sub_request_cbt"/>), a random nonce (see <xref target="sub_request_nonce"/>), and the ticket identifier (see <xref target="sub_request_tkt"/>).</t>
<t>
The initiator signs the re-authentication assertion with the ARK, using the hash algorithm associated with the original context key (see <xref target="sub_OID_Registry"/>; HS256 is specified for the encryption types referenced in this document).</t>
<t>
The re-authentication assertion is packed into a backed assertion. The certificate count is zero as the assertion is signed with an established symmetric key.</t>
<t>
The initiator generates an Authenticator Session Key (ASK) (see <xref target="sub_kd_ASK"/>) which is used to verify the response and derive the CRK.</t>
</list>
</t>
<t>
<cref>
Question: do we want an option to do an ECDH session key exchange in the fast re-auth case? If we had a GSS req_flag for requesting perfect forward security (PFS) then we would want to have this option.</cref>
</t>
</section>
<section title="Acceptor re-authentication context token" anchor="d1e1690">
<t>
<list style="numbers">
<t>
The acceptor unpacks the re-authentication assertion and retrieves the ARK, ticket expiry time, mutual authentication state and any other properties (such as the initiator name) associated with the ticket identifier.</t>
<t>
The acceptor validates that the ticket and re-authentication assertion have not expired.</t>
<t>
The acceptor verifies the assertion using the ARK.</t>
<t>
The acceptor generates the ASK (see <xref target="sub_kd_ASK"/>) and derives the RRK and CRK from this (see <xref target="sub_kd_RRK"/> and <xref target="sub_kd_CRK"/>, respectively).</t>
<t>
The acceptor generates a response and signs and returns it. Note that, unlike the certificate-based mutual authentication case, the nonce need not be echoed back as the ASK (and thus the RRK) is cryptographically bound to the nonce.</t>
</list>
</t>
<t>
If the ticket cannot be found, or the authentication fails, the acceptor SHOULD return a REAUTH_FAILED error, permitting the initiator to recover and fallback to generating a BrowserID assertion. It MAY also include its local timestamp (see <xref target="sub_response_iat"/>) so that the initiator can perform clock skew compensation.</t>
</section>
<section title="Interaction with mutual authentication" anchor="d1e1727">
<t>
The mutual authentication state of a re-authenticated context is transitive. The initiator and acceptor MUST NOT set the mutual_state flag for a re-authenticated context unless the original context was mutually authenticated.</t>
<t>
As such, the mutual authentication state of the original context must be associated with the ticket.</t>
</section>
<section title="Ticket renewal" anchor="d1e1739">
<t>
Normally, re-authentication tickets are only issued when the initiator authenticated with a certificate-signed assertion. Acceptors MAY issue a new ticket with an expiry beyond the ticket lifetime when the initiator used a re-authentication assertion. The issuing of new tickets MUST be subject to a policy that prevents them from being renewed indefinitely.</t>
</section>
</section>
<section title="Extra round-trip (XRT) option" anchor="sub_XRT_option">
<t>
The extra round-trip (XRT) option adds an additional round trip to the context token exchange. It allows the initiator to prove knowledge of the Context Master Key (CMK) (see <xref target="sub_kd_CMK"/>) by sending an additional token signed in a key derived from the CMK and an acceptor-issued challenge. Support for the XRT option is OPTIONAL in the acceptor and REQUIRED in the initiator. The initiator is allowed to not request it, but MUST perform XRT if the acceptor requires it.</t>
<t>
(Note that the term “extra round trip” is something of a misnomer; it only adds an additional token to the context token exchange. It is anticipated however that this mechanism will most commonly be used with pseudo-mechanisms or application protocols that require an even number of tokens.)</t>
<section title="Initiator XRT advertisement" anchor="d1e1766">
<t>
The initiator may advertise to the acceptor that it desires the XRT option by sending in its request assertion an “opts” claim (see <xref target="sub_request_opts"/>) containing the “xrt” value. This option MUST be set if the caller requested GSS_C_DCE_STYLE (see <xref target="RFC4757"/>). Otherwise, the setting of this option is implementation dependent.</t>
</section>
<section title="Acceptor XRT advertisement" anchor="d1e1784">
<t>
If the initiator requested the XRT option and the acceptor supports it, or the acceptor requires it, the acceptor sends a “jti” claim (see <xref target="sub_response_jti"/>) in the response assertion containing a random base 64 URL encoded value. This value MUST be at least 64 bits in length. The acceptor then returns GSS_C_CONTINUE_NEEDED to indicate that an additional context token is expected from the initiator.</t>
</section>
<section title="Initiator XRT context token" anchor="d1e1796">
<t>
If the acceptor indicated support for the XRT option by including a “jti” claim in its response, then the initiator sends an additional context token to the acceptor. This token contains the initiator context token ID concatenated with a backed assertion with zero certificates and an empty payload, signed using the XRTK (see <xref target="sub_kd_XRTK"/>).</t>
</section>
<section title="Acceptor XRT context token validation" anchor="d1e1808">
<t>
The acceptor MUST validate the XRT context token by first validating the context token ID, and then verifying the assertion signature with the XRTK. The acceptor SHOULD reject XRT context tokens with a certificate count greater than zero. Unknown claims in the assertion payload MUST be ignored. The acceptor then returns GSS_C_COMPLETE to the caller.</t>
<t>
The acceptor MAY avoid using a replay cache when this option is in effect.</t>
</section>
<section title="Interaction with message protection services" anchor="d1e1820">
<t>
When the XRT option is in effect, the XRTK is used instead of the CMK to derive the Context Root Key (CRK) (see <xref target="sub_kd_CRK"/>). Per-message tokens MUST have the AcceptorSubkey flag set (see <xref target="RFC4121"/> Section 4.2.2).</t>
</section>
</section>
</section>
<section title="Validation" anchor="d1e1839">
<section title="Expiry times" anchor="d1e1845">
<t>
The expiry and, if present, issued-at and not-before times of all elements in a backed assertion, MUST be validated. This applies equally to re-authentication assertions, public key assertions, and the entire certificate chain. If the expiry time is absent, the issued-at time MUST be present, and the JWT implicitly expires a short, implementation-defined interval after the issued-at time. (A suggested interval is five minutes.)</t>
<t>
The GSS context lifetime SHOULD NOT exceed the lifetime of the initiator principal's certificate.</t>
<t>
The lifetime of a re-authentication ticket SHOULD NOT exceed the lifetime of the initiator principal's certificate. The acceptor MUST validate the ticket expiry time when performing re-authentication.</t>
<t>
Message protections services such as GSS_Wrap() SHOULD be available beyond the GSS context lifetime for maximum application compatibility.</t>
</section>
<section title="Audience" anchor="d1e1863">
<t>
If the credential passed to GSS_Accept_sec_context() is not for GSS_C_NO_NAME, then its string representation as a BrowserID principal (see <xref target="sub_GSS_C_NT_BROWSERID_PRINCIPAL"/>) MUST match the audience claim in the assertion.</t>
</section>
<section title="Channel bindings" anchor="d1e1875">
<t>
GSS-API channel binding is a protected facility for naming an enclosing channel between the initiator and acceptor. If the acceptor passed in channel bindings to GSS_Accept_sec_context(), the assertion MUST contain a matching channel binding claim. (Only the application_data component is validated.)</t>
<t>
The acceptor SHOULD accept any channel binding provided by the initiator if NULL channel bindings are passed to GSS_Accept_sec_context().</t>
</section>
<section title="Key agreement" anchor="d1e1888">
<t>
The initiator MUST choose an ECDH curve with an equivalent strength to the negotiated <xref target="RFC4121"/> encryption type. Appropriate curves are given in <xref target="sub_OID_Registry"/>.</t>
<t>
The curve strength MUST be verified by the acceptor. A stronger than required curve MAY be selected by the initiator.</t>
</section>
<section title="Signatures" anchor="d1e1909">
<t>
Signature validation on assertions is the same as for the web usage of BrowserID, with the addition that response assertions may and re-authentication assertions must be signed with a symmetric key. In this case the HMAC algorithm associated with the mechanism OID is used, and there are no certificates in the backed assertion.</t>
</section>
<section title="Replay detection" anchor="sub_Replay_detection">
<t>
If the XRT option is not in effect, the acceptor MUST maintain a cache of received assertions in order to guard against replay attacks.</t>
</section>
<section title="Return flags" anchor="d1e1929">
<t>
The initiator and acceptor should set the returned flags as follows:</t>
<t>
<list style="hanging">
<t hangText="deleg_state">
never set</t>
<t hangText="mutual_state">
set if the initiator requested mutual authentication and mutual authentication succeeded</t>
<t hangText="replay_det_state">
set if message protection services are available</t>
<t hangText="sequence_state">
set if message protection services are available</t>
<t hangText="anon_state">
set if the initiator principal's leaf certificate lacks a “principal” claim</t>
<t hangText="trans_state">
set if the implementation supports importing and exporting of security contexts</t>
<t hangText="prot_ready_state">
may be set when or after the RP Response Token is produced or consumed</t>
<t hangText="conf_avail">
set if message protection services are available</t>
<t hangText="integ_avail">
set if message protection services are available</t>
</list>
</t>
</section>
</section>
<section title="Assertion claims" anchor="d1e1986">
<section title="Request (initiator/UA) assertion" anchor="d1e1992">
<t>
These claims are included in the assertion sent to the acceptor and are authenticated by the initiator's private key and certificate chain (directly, or in the case of re-authentication assertions, transitively). Claims not specified here MUST be ignored by the acceptor.</t>
<t>
Here is an example assertion containing Elliptic Curve Diffie-Hellman parameters, along with options and nonce claims indicating that mutual authentication is desired:</t>
<t>
</t>
<t>
<figure suppress-title="true" align="center">
<artwork> {
"opts": [
"ma"
],
"exp": 1360158396188,
"epk": {
"kty": "EC",
"crv": "P-256",
"x": "JR5UPDgMLFPZwOGaKKSF24658tB1DccM1_oHPbCHeZg",
"y": "S45Esx_6DfE5-xdB3X7sIIJ16MwO0Y_RiDc-i5ZTLQ8"
},
"nonce": "bbqT10Gyx3s",
"aud": "imap/mail.example.com"
}</artwork>
</figure>
</t>
<t>
The following claims are permitted in the request assertion:</t>
<section title="“aud” (Audience)" anchor="sub_request_aud">
<t>
The audience is a StringOrURI (see <xref target="I-D.ietf-oauth-json-web-token"/> Section 2) containing the target service's principal name, formatted according to <xref target="sub_GSS_C_NT_BROWSERID_PRINCIPAL"/>. This claim is REQUIRED. If the initiator specified a target name of GSS_C_NO_NAME, then the audience is the empty string.</t>
<t>
<cref>
If the initiator wanted mutual authentication then we could find out the acceptor's name and provide it via GSS_Inquire_context(). This is only really useful and secure with mechanisms like this one where the initiator credential is based on a public/private key pair and either we use key agreement and per-message tokens or channel binding to a secure channel. This really should [have] be[en] explained in RFC2743.</cref>
</t>
</section>
<section title="“exp” (Expiry time)" anchor="sub_request_exp">
<t>
This contains the time when the assertion expires, in milliseconds since January 1, 1970. At least one of “exp” or “iat” MUST be present.</t>
</section>
<section title="“iat” (Issued at time)" anchor="sub_request_iat">
<t>
This contains the time the assertion was issued (in milliseconds since January 1, 1970). If present, the acceptor MUST validate that the assertion was recently issued. At least one of “exp” or “iat” MUST be present.</t>
</section>
<section title="”nbf” (Not before time)" anchor="sub_request_nbf">
<t>
This contains the time, in milliseconds since January 1, 1970, from which the assertion begins to be valid. This claim is OPTIONAL.</t>
</section>
<section title=""epk" (Ephemeral Public Key)" anchor="sub_request_ecdh">
<t>
These contain key parameters for deriving a shared session key with the relying party, represented as a JSON Web Key <xref target="I-D.ietf-jose-json-web-key"/> public key value. The key type MUST be EC and the parameters for Elliptic Curve Public Keys specified in <xref target="I-D.ietf-jose-json-web-algorithms"/> Section 6.2.1 MUST be present.</t>
<t>
The “epk” claim is REQUIRED unless the associated encryption type is ENCTYPE_NULL, or there is already a prior session key (as is the case for re-authentication assertions).</t>
</section>
<section title="“cb” (Channel binding)" anchor="sub_request_cbt">
<t>
This contains channel binding information for binding the GSS context to an outer channel (e.g. see <xref target="RFC5929"/>). Its value is the base64 URL encoding of the application-specific data component of the channel bindings passed to GSS_Init_sec_context() or GSS_Accept_sec_context(). This claim is OPTIONAL.</t>
</section>
<section title=""nonce" (Mutual authentication nonce)" anchor="sub_request_nonce">
<t>
This is a random quantity of at least 64 bits, base 64 URL encoded, which is used to bind the request and response assertions in the case a freshly agreed key is not used to sign the response assertion. This claim is REQUIRED if mutual authentication is desired and the assertion is signed using a certificate, or if re-authentication is being performed.</t>
</section>
<section title="“tkt” (Ticket)" anchor="sub_request_tkt">
<t>
When the assertion is being used for fast re-authentication, this contains a JSON object with a single parameter, “tid”. The “tid” parameter matches the “tid” parameter from the initial response assertion ticket (see <xref target="sub_response_tkt"/>). This claim is REQUIRED for re-authentication assertions, otherwise it the assertion MUST be rejected. Other parameters SHOULD NOT be present in the “tkt” object.</t>
</section>
<section title="”opts” (Options)" anchor="sub_request_opts">
<t>
This contains a JSON array of string values indicating various protocol options that are supported by the initiator. Unknown options MUST be ignored by the acceptor. This document defines the following extensions:</t>
<texttable>
<ttcol align="center">
Name</ttcol>
<ttcol align="center">
Description</ttcol>
<c>
ma</c>
<c>
The initiator requested GSS_C_MUTUAL_FLAG</c>
<c>
xrt</c>
<c>
The initiator supports the extra round trip option (see Section 4.4)</c>
<c>
dce</c>
<c>
The initiator requested GSS_C_DCE_STYLE (see
RFC4757
Section 7.1)</c>
<c>
ify</c>
<c>
The initiator requested GSS_C_IDENTIFY_FLAG (see
RFC4757
Section 7.1)</c>
</texttable>
</section>
</section>
<section title="Response (acceptor/RP) assertion" anchor="d1e2226">
<t>
The response assertion is sent from the acceptor to the initiator to provide key agreement, and either key confirmation or mutual authentication. It is formatted as a backed assertion, however in the current specification it consists of a single assertion with zero certificates; that is, it is "unbacked". (It is encoded as a backed assertion in order to provide future support for mutual authentication using native BrowserID certificates. Such support is not specified here.)</t>
<t>
In the case of a key successfully being negotiated, the response assertion is signed with the RP Response Key (RRK) (see <xref target="sub_kd_RRK"/>). Alternatively, it may be signed with the acceptor's private RSA or DSA key. In this case, the acceptor's X.509 certificate is included in the "x5c" claim of the JWT header.</t>
<t>
The HMAC-SHA256 (HS256) algorithm MUST be supported by implementors of this specification.</t>
<t>
If the <xref target="RFC3961"/> encryption type for the mechanism is ENCTYPE_NULL, then the signature is absent and the value of the "alg" header parameter is "none". No signature verification is required in this case.</t>
<t>
Claims not specified here MUST be ignored by the initiator.</t>
<t>
Here is an example response assertion:</t>
<t>
</t>
<t>
<figure suppress-title="true" align="center">
<artwork>{
"exp": 1362960258000,
"nonce": "bbqT10Gyx3s",
"epk": {
"x": "bvNF6V1rpMeQyGOKCj0kBaOaSh3tlhUcbffaji4uCEI",
"y": "Iuqs650FXzXFUD9kHknETfbqiB8XBbCHlJXoysx3rvw"
},
"tkt": {
"tid": "Jgg7vKX2sEKlCWBfmLTg_n4qz3NVZxOU-a2B4qYMkXI",
"exp": 1362992660000
}
}</artwork>
</figure>
</t>
<t>
The following claims are permitted in the response assertion:</t>
<section title="“iat” (Issued at time)" anchor="sub_response_iat">
<t>
The current acceptor time, in milliseconds since January 1, 1970. This allows the initiator to compensate for clock differences when generating assertions. This claim is OPTIONAL.</t>
</section>
<section title="“epk” (Ephemeral Public Key)" anchor="sub_response_ecdh">
<t>
This contains a JSON object containing the x and y coordinates of the acceptor's ECDH public key (see <xref target="I-D.ietf-jose-json-web-algorithms"/> Section 6.2.1). This claim is REQUIRED unless the associated encryption type is ENCTYPE_NULL, or there is already an established session key, as is the case for re-authentication assertions.</t>
<t>
The “crv” and “kty” properties SHOULD NOT be present; they are determined by the initiator.</t>
</section>
<section title="“exp” (Expiry time)" anchor="sub_response_exp">
<t>
This contains the time when the context expires, in milliseconds since January 1, 1970. This claim is OPTIONAL; the initiator should use the certificate or ticket expiry time if absent.</t>
</section>
<section title="“nonce” (Mutual authentication nonce)" anchor="sub_response_nonce">
<t>
The nonce as received from the initiator. This MUST NOT be present unless a nonce was received from the initiator, and the acceptor is signing the assertion with a private key.</t>
</section>
<section title="“tkt” (Ticket)" anchor="sub_response_tkt">
<t>
This contains a JSON object that may be used for re-authenticating to the acceptor without acquiring an assertion. It has two parameters: “tid”, an opaque identifier to be presented in a re-authentication assertion (this need not be a string); and “exp”, the expiry time of the ticket. This claim is OPTIONAL.</t>
</section>
<section title="”jti” (JWT ID)" anchor="sub_response_jti">
<t>
This contains a base64 URL encoded random value of at least 64 bits that is used to uniquely identify the acceptor response, in the case that the extra round trip option is used. It SHOULD not be present unless the initiator requested the extra round trip option.</t>
</section>
</section>
<section title="Error (acceptor/RP) assertion" anchor="d1e2345">
<t>
Error assertions are backed assertions containing any or all of the following claims. In addition, they MUST have the “iat” claim, for initiator clock skew correction. All other response assertion claims are OPTIONAL or not applicable in error assertions. Conversely, the claims listed below MUST NOT be present in a non-error response assertion.</t>
<t>
The error assertion MAY be signed if a key is available, otherwise the signature is absent and the value of the "alg" header parameter is "none".</t>
<section title="“gss-maj” (GSS major status code)" anchor="sub_response_gss_maj">
<t>
This contains a GSS major status code represented as a number.</t>
</section>
<section title="“gss-min” (GSS minor status code)" anchor="sub_response_gss_min">
<t>
This contains a GSS minor status code represented as a number.</t>
<t>
If REAUTH_FAILED is received, the initiator SHOULD attempt to send another initial context token containing a fresh assertion.</t>
<t>
The following protocol minor status codes are defined. Note that the API representation of these status codes is implementation dependent. Status codes with the high bit set are GSS BrowserID protocol errors; the remainder are BrowserID protocol errors.</t>
<texttable>
<ttcol align="center">
Error</ttcol>
<ttcol align="center">
Protocol</ttcol>
<ttcol align="center">
Description</ttcol>
<c>
INVALID_JSON</c>
<c>
8</c>
<c>
Invalid JSON encoding</c>
<c>
INVALID_BASE64</c>
<c>
9</c>
<c>
Invalid Base64 encoding</c>
<c>
INVALID_ASSERTION</c>
<c>
10</c>
<c>
Invalid assertion</c>
<c>
TOO_MANY_CERTS</c>
<c>
13</c>
<c>
Too many certificates</c>
<c>
UNTRUSTED_ISSUER</c>
<c>
14</c>
<c>
Untrusted issuer</c>
<c>
INVALID_ISSUER</c>
<c>
15</c>
<c>
Invalid issuer</c>
<c>
MISSING_ISSUER</c>
<c>
16</c>
<c>
Missing issuer</c>
<c>
MISSING_AUDIENCE</c>
<c>
17</c>
<c>
Missing audience</c>
<c>
BAD_AUDIENCE</c>
<c>
18</c>
<c>
Bad audience</c>
<c>
EXPIRED_ASSERTION</c>
<c>
19</c>
<c>
Assertion expired</c>
<c>
ASSERTION_NOT_YET_VALID</c>
<c>
20</c>
<c>
Assertion not yet valid</c>
<c>
EXPIRED_CERT</c>
<c>
21</c>
<c>
Certificate expired</c>
<c>
CERT_NOT_YET_VALID</c>
<c>
22</c>
<c>
Certificate not yet valid</c>
<c>
INVALID_SIGNATURE</c>
<c>
23</c>
<c>
Invalid signature</c>
<c>
MISSING_ALGORITHM</c>
<c>
24</c>
<c>
Missing JWS algorithm</c>
<c>
UNKNOWN_ALGORITHM</c>
<c>
25</c>
<c>
Unknown JWS algorithm</c>
<c>
MISSING_PRINCIPAL</c>
<c>
34</c>
<c>
Missing principal attribute</c>
<c>
UNKNOWN_PRINCIPAL_TYPE</c>
<c>
35</c>
<c>
Unknown principal type</c>
<c>
MISSING_CERT</c>
<c>
36</c>
<c>
Missing certificate</c>
<c>
MISSING_CHANNEL_BINDINGS</c>
<c>
38</c>
<c>
Missing channel bindings</c>
<c>
CHANNEL_BINDINGS_MISMATCH</c>
<c>
39</c>
<c>
Channel bindings do not match</c>
<c>
NOT_REAUTH_ASSERTION</c>
<c>
70</c>
<c>
Not a re-authentication assertion</c>
<c>
BAD_SUBJECT</c>
<c>
71</c>
<c>
Bad subject name</c>
<c>
MISMATCHED_RP_RESPONSE</c>
<c>
72</c>
<c>
Mismatched RP response token</c>
<c>
REFLECTED_RP_RESPOSNE</c>
<c>
73</c>
<c>
Reflected RP response token</c>
<c>
UNKNOWN_EC_CURVE</c>
<c>
77</c>
<c>
Unknown ECC curve</c>
<c>
INVALID_EC_CURVE</c>
<c>
78</c>
<c>
Invalid ECC curve</c>
<c>
MISSING_NONCE</c>
<c>
79</c>
<c>
Missing nonce</c>
<c>
WRONG_SIZE</c>
<c>
0x80000001</c>
<c>
Buffer is incorrect size</c>
<c>
WRONG_MECH</c>
<c>
0x80000002</c>
<c>
Mechanism OID is incorrect</c>
<c>
BAD_TOK_HEADER</c>
<c>
0x80000003</c>
<c>
Token header is malformed or corrupt</c>
<c>
TOK_TRUNC</c>
<c>
0x80000004</c>
<c>
Token is missing data</c>
<c>
BAD_DIRECTION</c>
<c>
0x80000005</c>
<c>
Packet was replayed in wrong direction</c>
<c>
WRONG_TOK_ID</c>
<c>
0x80000006</c>
<c>
Received token ID does not match expected</c>
<c>
KEY_UNAVAILABLE</c>
<c>
0x80000007</c>
<c>
Key unavailable</c>
<c>
KEY_TOO_SHORT</c>
<c>
0x80000008</c>
<c>
Key too weak</c>
<c>
CONTEXT_ESTABLISHED</c>
<c>
0x80000009</c>
<c>
Context already established</c>
<c>
CONTEXT_INCOMPLETE</c>
<c>
0x8000000A</c>
<c>
Context incomplete</c>
<c>
BAD_CONTEXT_TOKEN</c>
<c>
0x8000000B</c>
<c>
Context token malformed or corrupt</c>
<c>