1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
|
<pre>Internet Engineering Task Force (IETF) E. Lear
Request for Comments: 6616 Cisco Systems GmbH
Category: Standards Track H. Tschofenig
ISSN: 2070-1721 Nokia Siemens Networks
H. Mauldin
Cisco Systems, Inc.
S. Josefsson
SJD AB
May 2012
<span class="h1">A Simple Authentication and Security Layer (SASL) and</span>
<span class="h1">Generic Security Service Application Program Interface (GSS-API)</span>
<span class="h1">Mechanism for OpenID</span>
Abstract
OpenID has found its usage on the Internet for Web Single Sign-On.
Simple Authentication and Security Layer (SASL) and the Generic
Security Service Application Program Interface (GSS-API) are
application frameworks to generalize authentication. This memo
specifies a SASL and GSS-API mechanism for OpenID that allows the
integration of existing OpenID Identity Providers with applications
using SASL and GSS-API.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6616">http://www.rfc-editor.org/info/rfc6616</a>.
<span class="grey">Lear, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6616">RFC 6616</a> SASL & GSS-API Mechanism for OpenID May 2012</span>
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-1.2">1.2</a>. Applicability . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2">2</a>. Applicability for Application Protocols other than HTTP . . . <a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. Binding SASL to OpenID in the Relying Party . . . . . . . <a href="#page-7">7</a>
<a href="#section-2.2">2.2</a>. Discussion . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3">3</a>. OpenID SASL Mechanism Specification . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.1">3.1</a>. Initiation . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3.2">3.2</a>. Authentication Request . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3.3">3.3</a>. Server Response . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-3.4">3.4</a>. Error Handling . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4">4</a>. OpenID GSS-API Mechanism Specification . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.1">4.1</a>. GSS-API Principal Name Types for OpenID . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5">5</a>. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-6.1">6.1</a>. Binding OpenIDs to Authorization Identities . . . . . . . <a href="#page-14">14</a>
6.2. RP Redirected by Malicious URL to Take an Improper
Action . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-6.3">6.3</a>. User Privacy . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-7">7</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-8">8</a>. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-9">9</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-9.1">9.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-9.2">9.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<span class="grey">Lear, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6616">RFC 6616</a> SASL & GSS-API Mechanism for OpenID May 2012</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
OpenID 2.0 [<a href="#ref-OpenID" title=""OpenID Authentication 2.0 - Final"">OpenID</a>] is a web-based three-party protocol that provides
a means for a user to offer identity assertions and other attributes
to a web server (Relying Party) via the help of an identity provider.
The purpose of this system is to provide a way to verify that an end
user controls an identifier.
Simple Authentication and Security Layer (SASL) [<a href="./rfc4422" title=""Simple Authentication and Security Layer (SASL)"">RFC4422</a>] is used by
application protocols such as IMAP [<a href="./rfc3501" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">RFC3501</a>], Post Office Protocol
(POP) [<a href="./rfc1939" title=""Post Office Protocol - Version 3"">RFC1939</a>], and Extensible Messaging and Presence Protocol
(XMPP) [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>], with the goal of modularizing authentication and
security layers, so that newer mechanisms can be added as needed.
This memo specifies just such a mechanism.
The Generic Security Service Application Program Interface (GSS-API)
[<a href="./rfc2743" title=""Generic Security Service Application Program Interface Version 2, Update 1"">RFC2743</a>] provides a framework for applications to support multiple
authentication mechanisms through a unified interface. This document
defines a pure SASL mechanism for OpenID, but it conforms to the new
bridge between SASL and the GSS-API called GS2 [<a href="./rfc5801" title=""Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family"">RFC5801</a>]. This means
that this document defines both a SASL mechanism and a GSS-API
mechanism. Implementors of the SASL component MAY implement the GSS-
API interface as well.
This mechanism specifies interworking between SASL and OpenID in
order to assert identity and other attributes to Relying Parties. As
such, while SASL servers (as Relying Parties) will advertise SASL
mechanisms, clients will select the OpenID mechanism.
The OpenID mechanism described in this memo aims to reuse the OpenID
mechanism to the maximum extent and therefore does not establish a
separate authentication, integrity, and confidentiality mechanism.
It is anticipated that existing security layers, such as Transport
Layer Security (TLS) [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>], continue to be used. Minimal changes
are required to non-web applications, as most of the transaction
occurs through a normal web browser. Hence, this specification is
only appropriate for use when such a browser is available.
Figure 1 describes the interworking between OpenID and SASL. This
document requires enhancements to the Relying Party and to the Client
(as the two SASL communication end points), but no changes to the
OpenID Provider (OP) are necessary. To accomplish this goal,
indirect messaging required by the OpenID specification is tunneled
through the SASL/GSS-API mechanism.
<span class="grey">Lear, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6616">RFC 6616</a> SASL & GSS-API Mechanism for OpenID May 2012</span>
+-----------+
| Relying |
>| Party / |
/ | SASL |
// | Server |
// +-----------+
// ^
OpenID // +--|--+
// | O| | G
/ S | p| | S
// A | e| | S
// S | n| | A
// L | I| | P
// | D| | I
</ +--|--+
+------------+ v
| | +----------+
| OpenID | OpenID | |
| Provider |<--------------->| Client |
| | | |
+------------+ +----------+
Figure 1: Interworking Architecture
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
The reader is assumed to be familiar with the terms used in the
OpenID 2.0 specification.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Applicability</span>
Because this mechanism transports information that should not be
controlled by an attacker, the OpenID mechanism MUST only be used
over channels protected by TLS, and the client MUST successfully
validate the server certificate [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>][RFC6125].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Applicability for Application Protocols other than HTTP</span>
OpenID was originally envisioned for HTTP- [<a href="./rfc2616" title=""Hypertext Transfer Protocol -- HTTP/1.1"">RFC2616</a>] and HTML-based
[<a href="#ref-W3C.REC-html401-19991224">W3C.REC-html401-19991224</a>] communications, and with the associated
semantic; the idea being that the user would be redirected by the
Relying Party (RP) to an identity provider (IdP) who authenticates
the user and then sends identity information and other attributes
(either directly or indirectly) to the Relying Party. The identity
<span class="grey">Lear, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6616">RFC 6616</a> SASL & GSS-API Mechanism for OpenID May 2012</span>
provider in the OpenID specifications is referred to as an OpenID
Provider (OP). The actual protocol flow can be found in <a href="#section-3">Section 3</a> of
the OpenID 2.0 specification [<a href="#ref-OpenID" title=""OpenID Authentication 2.0 - Final"">OpenID</a>]. The reader is strongly
encouraged to be familiar with that specification before continuing.
When considering that flow in the context of SASL, we note that while
the RP and the client both need to change their code to implement
this SASL mechanism, it is a design constraint that the OP behavior
remain untouched, in order for implementations to interoperate with
existing IdPs. Hence, an analog flow that interfaces the three
parties needs to be created. In the analog, we note that unlike a
web server, the SASL server already has some sort of session
(probably a TCP connection) established with the client. However, it
may be necessary for a SASL client to invoke to another application.
This will be discussed below. By doing so, we externalize much of
the authentication from SASL.
The steps are listed below:
1. The SASL server advertises support for the SASL OpenID mechanism
to the client.
2. The client initiates a SASL authentication and transmits the
User-Supplied Identifier as its first response. The SASL
mechanism is client-first, and, as explained in [<a href="./rfc4422" title=""Simple Authentication and Security Layer (SASL)"">RFC4422</a>], the
server will send an empty challenge if needed.
3. After normalizing the User-Supplied Identifier as discussed in
[<a href="#ref-OpenID" title=""OpenID Authentication 2.0 - Final"">OpenID</a>], the Relying Party performs discovery on it and
establishes the OP Endpoint URL that the end user uses for
authentication.
4. The Relying Party and the OP optionally establish an association
-- a shared secret established using Diffie-Hellman Key
Exchange. The OP uses an association to validate those messages
through the use of a Hashed Message Authentication Code (HMAC);
this removes the need for subsequent direct requests to verify
the signature after each authentication request/response.
5. The Relying Party transmits an authentication request to the OP
to obtain an assertion in the form of an indirect request.
These messages are passed through the client rather than
directly between the RP and the OP. OpenID defines two methods
for indirect communication -- namely, HTTP redirects and HTML
form submission. Neither mechanism is directly applicable for
usage with SASL. To ensure that an OP that is OpenID 2.0
capable can be used, a new method is defined in this document
that requires the OpenID message content to be encoded using a
<span class="grey">Lear, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6616">RFC 6616</a> SASL & GSS-API Mechanism for OpenID May 2012</span>
Universal Resource Identifier (URI) [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>]. Note that any
Internationalized Resource Identifiers (IRIs) must be normalized
to URIs by the SASL client, as specified in [<a href="./rfc3987" title=""Internationalized Resource Identifiers (IRIs)"">RFC3987</a>], prior to
transmitting them to the SASL server.
6. The SASL client now sends a response consisting of "=" to the
server, to indicate that authentication continues via the normal
OpenID flow.
7. At this point, the client application MUST construct a URL
containing the content received in the previous message from the
RP. This URL is transmitted to the OP by either the SASL client
application or an appropriate handler, such as a browser.
8. Next, the end user optionally authenticates to the OP and then,
depending on the OP, may approve or disapprove authentication to
the Relying Party. For reasons of its own, the OP has the
option of not authenticating a request. The manner in which the
end user is authenticated to their respective OP and any
policies surrounding such authentication are out of scope of
OpenID and, hence, also out of scope for this specification.
This step happens out of band from SASL.
9. The OP will convey information about the success or failure of
the authentication phase back to the RP, again using an indirect
response via the client browser or handler. The client
transmits to the RP (over HTTP/TLS) the redirect of the OP
result. This step happens out of band from SASL.
10. The RP MAY send an OpenID check_authentication request directly
to the OP, if no association has been established, and the OP
should respond. Again, this step happens out of band from SASL.
11. The SASL server sends an appropriate SASL response to the
client, with optional Open Simple Registry (SREG) attributes.
<span class="grey">Lear, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6616">RFC 6616</a> SASL & GSS-API Mechanism for OpenID May 2012</span>
SASL Serv. RP/Client OP
|>-----(1)----->| | Advertisement
| | |
|<-----(2)-----<| | Initiation
| | |
|> - - (3) - - - - - - - - - ->| Discovery
| |
|>- - -(4)- - - - - - - - - - >| Association
|<- - -(4)- - - - - - - - - - <|
| | |
|>-----(5)----->| | Indirect Auth Request
| | |
|<-----(6)-----<| | Client "=" Response
| | |
| |>- - (7)- - ->| Client GET to the OP (ext.)
| | |
| |<- - (8)- - ->| Client / OP Auth. (ext.)
| | |
|<- - -(9)- - - + - - - - - - <| HTTPS Indirect id_res
| | |
|<- - -(10)- - - - - - - - - ->| Optional
| | | check_authentication
| | |
|>-----(11)---->| | SASL completion with status
----- = SASL
- - - = HTTPS
Note the directionality in SASL is such that the client MUST send the
"=" response. Specifically, the SASL client processes the redirect
and then awaits a final SASL decision, while the rest of the OpenID
authentication process continues.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Binding SASL to OpenID in the Relying Party</span>
OpenID is meant to be used in serial within the web, where browser
cookies are easily accessible. As such, there are no transaction IDs
within the protocol. To ensure that a specific request is bound, and
in particular to ease inter-process communication, the Relying Party
MUST encode a nonce or transaction ID in the URIs it transmits
through the client for success or failure, as either a base URI or
fragment component to the "return_to" URI. This value is to be used
to uniquely identify each authentication transaction. The nonce
value MUST be at least 2^32 bits and large enough to handle well in
excess of the number of concurrent transactions a SASL server shall
see.
<span class="grey">Lear, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6616">RFC 6616</a> SASL & GSS-API Mechanism for OpenID May 2012</span>
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Discussion</span>
As mentioned above, OpenID is primarily designed to interact with
web-based applications. Portions of the authentication stream are
only defined in the crudest sense. That is, when one is prompted to
approve or disapprove an authentication, anything that one might find
on a browser is allowed, including JavaScript, complex style-sheets,
etc. Because of this lack of structure, implementations will need to
invoke a rich browser in order to ensure that the authentication can
be completed.
Once there is an outcome, the SASL server needs to know about it.
The astute reader will hopefully by now have noticed an "=" client
SASL response. This is not to say that nothing is happening, but
rather that authentication flow has shifted from SASL and the client
application to OpenID within the browser, and it will return to the
client application when the server has an outcome to hand to the
client. The alternative to this flow would be some sort of signal
from the HTML browser to the SASL client of the results that would in
turn be passed to the SASL server. The inter-process communication
issue this raises is substantial. Better, we conclude, to
externalize the authentication to the browser and have an "=" client
response.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. OpenID SASL Mechanism Specification</span>
This section specifies the details of the OpenID SASL mechanism.
Recall <a href="./rfc4422#section-5">Section 5 of [RFC4422]</a> for what needs to be described here.
The name of this mechanism is "OPENID20". The mechanism is capable
of transferring an authorization identity (via "gs2-header"). The
mechanism does not offer a security layer.
The mechanism is client-first. The first mechanism message is from
the client to the server, and it is the "initial-response" described
below. As described in [<a href="./rfc4422" title=""Simple Authentication and Security Layer (SASL)"">RFC4422</a>], if the application protocol does
not support sending a client-response together with the
authentication request, the server will send an empty server-
challenge to let the client begin.
The second mechanism message is from the server to the client, and it
is the "authentication_request" described below.
The third mechanism message is from client to the server, and it is
the fixed message consisting of "=".
<span class="grey">Lear, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6616">RFC 6616</a> SASL & GSS-API Mechanism for OpenID May 2012</span>
The fourth mechanism message is from the server to the client,
described below as "outcome_data" (with SREG attributes), sent as
additional data when indicating a successful outcome.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Initiation</span>
A client initiates an OpenID authentication with SASL by sending the
GS2 header followed by the URI, as specified in the OpenID
specification.
The ABNF [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>] syntax is as follows:
initial-response = gs2-header Auth-Identifier
Auth-Identifier = Identifier ; authentication identifier
Identifier = URI ; Identifier is specified in
; Sec. 7.2 of the OpenID 2.0 spec.
The syntax and semantics of the "gs2-header" are specified in
[<a href="./rfc5801" title=""Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family"">RFC5801</a>], and we use it here with the following limitations: The
"gs2-nonstd-flag" MUST NOT be present. The "gs2-cb-flag" MUST be "n"
because channel binding is not supported by this mechanism.
URI is specified in [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>]. Extensible Resource Identifiers
(XRIs) [<a href="#ref-XRI2.0" title=""Extensible Resource Identifier (XRI) Syntax V2.0"">XRI2.0</a>] MUST NOT be used.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Authentication Request</span>
The SASL server sends the URL resulting from the OpenID
authentication request, containing an "openid.mode" of either
"checkid_immediate" or "checkid_setup", as specified in <a href="#section-9.1">Section 9.1</a>
of the OpenID 2.0 specification [<a href="#ref-OpenID" title=""OpenID Authentication 2.0 - Final"">OpenID</a>].
authentication-request = URI
As part of this request, the SASL server MUST append a unique
transaction ID to the "return_to" portion of the request. The form
of this transaction is left to the RP to decide, but it SHOULD be
large enough to be resistant to being guessed or attacked.
The client now sends that request via an HTTP GET to the OP, as if
redirected to do so from an HTTP server.
The client MUST handle both user authentication to the OP and
confirmation or rejection of the authentication by the RP via this
SASL mechanism.
<span class="grey">Lear, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6616">RFC 6616</a> SASL & GSS-API Mechanism for OpenID May 2012</span>
After all authentication has been completed by the OP, and after the
response has been sent to the client, the client will relay the
response to the Relying Party via HTTP/TLS, as specified previously
in the transaction ("return_to").
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Server Response</span>
The Relying Party now validates the response it received from the
client via HTTP/TLS, as specified in the OpenID specification, using
the "return_to" URI given previously in the transaction.
The response by the Relying Party constitutes a SASL mechanism
outcome, and it SHALL be used to set state in the server accordingly.
Also, it SHALL be used by the server to report that state to the SASL
client as described in <a href="./rfc4422#section-3.6">Section 3.6 of [RFC4422]</a>. In the additional
data, the server MAY include OpenID Simple Registry (SREG) attributes
that are listed in Section 4 of [<a href="#ref-SREG1.0" title=""OpenID Simple Registration Extension version 1.0"">SREG1.0</a>]. SREG attributes are
encoded as follows:
1. Strip "openid.sreg." from each attribute name.
2. Treat the concatenation of results as URI parameters that are
separated by an ampersand (&) and encode as one would a URI,
absent the scheme, authority, and the question mark.
For example: email=lear@example.com&fullname=Eliot%20Lear
More formally:
outcome-data = [ sreg-avp *( "," sreg-avp ) ]
sreg-avp = sreg-attr "=" sreg-val
sreg-attr = sreg-word
sreg-val = sreg-word
sreg-word = 1*( unreserved / pct-encoded )
; pct-encoded from <a href="./rfc3986#section-2.1">Section 2.1 of RFC 3986</a>
; unreserved from <a href="./rfc3986#section-2.3">Section 2.3 of RFC 3986</a>
A client who does not support SREG MUST ignore SREG attributes sent
by the server. Similarly, a client MUST ignore unknown attributes.
In the case of failures, the response MUST follow this syntax:
outcome-data = "openid.error" "=" sreg-val *( "," sregp-avp )
<span class="grey">Lear, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6616">RFC 6616</a> SASL & GSS-API Mechanism for OpenID May 2012</span>
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Error Handling</span>
<a href="./rfc4422#section-3.6">Section 3.6 of [RFC4422]</a> explicitly prohibits additional information
in an unsuccessful authentication outcome. Therefore, the
openid.error and openid.error_code are to be sent as an additional
challenge in the event of an unsuccessful outcome. In this case, as
the protocol is in lockstep, the client will follow with an
additional exchange containing "=", after which the server will
respond with an application-level outcome.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. OpenID GSS-API Mechanism Specification</span>
This section MUST be observed to properly implement the GSS-API
mechanism that is described below.
The OpenID SASL mechanism is actually also a GSS-API mechanism. The
OpenID user takes the role of the GSS-API Initiator and the OpenID
Relying Party takes the role of the GSS-API Acceptor. The OpenID
Provider does not have a role in GSS-API and is considered an
internal matter for the OpenID mechanism. The messages are the same,
but a) the GS2 header on the client's first message and channel
binding data are excluded when OpenID is used as a GSS-API mechanism,
and b) the initial context token header (described in <a href="./rfc2743#section-3.1">Section 3.1 of
RFC 2743</a>) is prefixed to the client's first authentication message
(context token).
The GSS-API OID for the OpenID 2.0 mechanism is 1.3.6.1.5.5.16 (see
<a href="#section-7">Section 7</a> for more information). The DER encoding of the OID is 0x2b
0x06 0x01 0x05 0x05 0x10.
OpenID security contexts MUST have the mutual_state flag
(GSS_C_MUTUAL_FLAG) set to TRUE. OpenID does not support credential
delegation; therefore, OpenID security contexts MUST have the
deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE.
The mutual authentication property of this mechanism relies on
successfully comparing the TLS server identity with the negotiated
target name. Since the TLS channel is managed by the application
outside of the GSS-API mechanism, the mechanism itself is unable to
confirm the name while the application is able to perform this
comparison for the mechanism. For this reason, applications MUST
match the TLS server identity with the target name, as discussed in
[<a href="./rfc6125" title=""Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)"">RFC6125</a>].
The OpenID mechanism does not support per-message tokens or
GSS_Pseudo_random.
<span class="grey">Lear, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6616">RFC 6616</a> SASL & GSS-API Mechanism for OpenID May 2012</span>
The [<a href="./rfc5587" title=""Extended Generic Security Service Mechanism Inquiry APIs"">RFC5587</a>] mechanism attributes for this mechanism are
GSS_C_MA_MECH_CONCRETE, GSS_C_MA_ITOK_FRAMED, and GSS_C_MA_AUTH_INIT.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. GSS-API Principal Name Types for OpenID</span>
OpenID supports standard generic name syntaxes for acceptors such as
GSS_C_NT_HOSTBASED_SERVICE (see <a href="./rfc2743#section-4.1">Section 4.1 of [RFC2743]</a>).
OpenID supports only a single name type for initiators:
GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for
OpenID.
OpenID name normalization is covered by the OpenID specification; see
Section 7.2 of [<a href="#ref-OpenID" title=""OpenID Authentication 2.0 - Final"">OpenID</a>].
The query, display, and exported name syntaxes for OpenID principal
names are all the same. There are no OpenID-specific name syntaxes
-- applications should use generic GSS-API name types such as
GSS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE (see <a href="./rfc2743#section-4">Section 4 of
[RFC2743]</a>). The exported name token does, of course, conform to
<a href="./rfc2743#section-3.2">Section 3.2 of [RFC2743]</a>, but the "NAME" part of the token should be
treated as a potential input string to the OpenID name normalization
rules. For example, the OpenID Identifier "https://openid.example/"
will have a GSS_C_NT_USER_NAME value of "https://openid.example/".
GSS-API name attributes may be defined in the future to hold the
normalized OpenID Identifier.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Example</span>
Suppose a user has an OpenID of https://openid.example and wishes to
authenticate his IMAP connection to mail.example (where .example is
the top-level domain specified in [<a href="./rfc2606" title=""Reserved Top Level DNS Names"">RFC2606</a>]). The user would input
his OpenID into his mail user agent when he configures the account.
In this case, no association is attempted between the OpenID RP and
the OP. The client will make use of the "return_to" attribute to
capture results of the authentication to be redirected to the server.
Note the use of [<a href="./rfc4959" title=""IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response"">RFC4959</a>] for the initial response. The
authentication on the wire would then look something like the
following:
<span class="grey">Lear, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6616">RFC 6616</a> SASL & GSS-API Mechanism for OpenID May 2012</span>
(S = IMAP server; C = IMAP client)
C: < connects to IMAP port>
S: * OK
C: C1 CAPABILITY
S: * CAPABILITY IMAP4rev1 SASL-IR SORT [...] AUTH=OPENID20
S: C1 OK Capability Completed
C: C2 AUTHENTICATE OPENID biwsaHR0cHM6Ly9vcGVuaWQuZXhhbXBsZS8=
[ This is the base64 encoding of "n,,https://openid.example/".
Server performs discovery on http://openid.example/ ]
S: + aHR0cHM6Ly9vcGVuaWQuZXhhbXBsZS9vcGVuaWQvP29wZW5pZC5ucz1
odHRwOi8vc3BlY3Mub3BlbmlkLm5ldC9hdXRoLzIuMCZvcGVuaWQucm
V0dXJuX3RvPWh0dHBzOi8vbWFpbC5leGFtcGxlL2NvbnN1bWVyLzFlZ
jg4OGMmb3BlbmlkLmNsYWltZWRfaWQ9aHR0cHM6Ly9vcGVuaWQuZXhh
bXBsZS8mb3BlbmlkLmlkZW50aXR5PWh0dHBzOi8vb3BlbmlkLmV4YW1
wbGUvJm9wZW5pZC5yZWFsbT1pbWFwOi8vbWFpbC5leGFtcGxlJm9wZW
5pZC5tb2RlPWNoZWNraWRfc2V0dXA=
[ This is the base64 encoding of "https://openid.example/openid/
?openid.ns=http://specs.openid.net/auth/2.0
&openid.return_to=https://mail.example/consumer/1ef888c
&openid.claimed_id=https://openid.example/
&openid.identity=https://openid.example/
&openid.realm=imap://mail.example
&openid.mode=checkid_setup"
with line breaks and spaces added here for readability.
]
C: PQ==
[ The client now sends the URL it received to a browser for
processing. The user logs into https://openid.example and
agrees to authenticate imap://mail.example. A redirect is
passed back to the client browser that then connects to
https://imap.example/consumer via SSL with the results.
From an IMAP perspective, however, the client sends the "="
response, and awaits mail.example.
Server mail.example would now contact openid.example with an
openid.check_authentication message. After that...
]
S: + ZW1haWw9bGVhckBtYWlsLmV4YW1wbGUsZnVsbG5hbWU9RWxp
b3QlMjBMZWFy
[ Here, the IMAP server has returned an SREG attribute of
email=lear@mail.example,fullname=Eliot%20Lear.
Line break in response added in this example for readability. ]
C:
[ In IMAP, client must send a blank response after receiving
the SREG data. ]
S: C2 OK
<span class="grey">Lear, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6616">RFC 6616</a> SASL & GSS-API Mechanism for OpenID May 2012</span>
In this example, the SASL server / RP has made use of a transaction
ID 1ef888c.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
This section will address only security considerations associated
with the use of OpenID with SASL and GSS-API. For considerations
relating to OpenID in general, the reader is referred to the OpenID
specification [<a href="#ref-OpenID" title=""OpenID Authentication 2.0 - Final"">OpenID</a>] and to other literature [<a href="#ref-OpReview" title=""Google Sites OpenID Reference Page"">OpReview</a>].
Similarly, for general SASL [<a href="./rfc4422" title=""Simple Authentication and Security Layer (SASL)"">RFC4422</a>] and GSS-API [<a href="./rfc5801" title=""Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family"">RFC5801</a>] security
considerations, the reader is referred to those specifications.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Binding OpenIDs to Authorization Identities</span>
As specified in [<a href="./rfc4422" title=""Simple Authentication and Security Layer (SASL)"">RFC4422</a>], the server is responsible for binding
credentials to a specific authorization identity. It is therefore
necessary that a registration process takes place in advance that
binds specific OpenIDs to specific authorization identities, or that
only specific trusted OpenID Providers be allowed, where a mapping is
predefined. For example, it could be prearranged between an IdP and
RP that "https://example.com/user" maps to "user" for purposes of
authorization.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. RP Redirected by Malicious URL to Take an Improper Action</span>
In the initial SASL client response, a user or host can transmit a
malicious response to the RP for purposes of taking advantage of
weaknesses in the RP's OpenID implementation. It is possible to add
port numbers to the URL so that the outcome is that the RP does a
port scan of the site. The URL could contain an unauthorized host or
even the local host. The URL could contain a protocol other than
http or https, such as file or ftp.
One mitigation would be for RPs to have a list of authorized URI
bases. OPs SHOULD only redirect to RPs with the same domain
component of the base URI. RPs MUST NOT automatically retry on
failed attempts. A log of those sites that fail SHOULD be kept, and
limitations on queries from clients SHOULD be imposed, just as with
any other authentication attempt. Applications SHOULD NOT invoke
browsers to communicate with OPs that they are not themselves
configured with.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. User Privacy</span>
The OP is aware of each RP that a user logs into. There is nothing
in the protocol to hide this information from the OP. It is not a
requirement to track the visits, but there is nothing that prohibits
the collection of information. SASL servers should be aware that
<span class="grey">Lear, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6616">RFC 6616</a> SASL & GSS-API Mechanism for OpenID May 2012</span>
OpenID Providers will be able to track -- to some extent -- user
access to their services and any additional information that OP
provides.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
IANA has updated the "SASL Mechanisms" registry using the following
template, as described in [<a href="./rfc4422" title=""Simple Authentication and Security Layer (SASL)"">RFC4422</a>].
SASL mechanism name: OPENID20
Security Considerations: See this document
Published specification: See this document
Person & email address to contact for further information: Authors of
this document
Intended usage: COMMON
Owner/Change controller: IESG
Note: None
IANA has also assigned an OID for this GSS mechanism in the "SMI
Security for Mechanism Codes" registry, with the prefix of
iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and
referencing this specification in the registry.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgments</span>
The authors would like to thank Alexey Melnikov, Joe Hildebrand, Mark
Crispin, Chris Newman, Leif Johansson, Sam Hartman, Nico Williams,
Klaas Wierenga, Stephen Farrell, and Stephen Kent for their review
and contributions.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-OpenID">OpenID</a>] OpenID Foundation, "OpenID Authentication 2.0 - Final",
December 2007, <<a href="http://specs.openid.net/auth/2.0">http://specs.openid.net/auth/2.0</a>>.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC2606">RFC2606</a>] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", <a href="https://www.rfc-editor.org/bcp/bcp32">BCP 32</a>, <a href="./rfc2606">RFC 2606</a>, June 1999.
<span class="grey">Lear, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6616">RFC 6616</a> SASL & GSS-API Mechanism for OpenID May 2012</span>
[<a id="ref-RFC2616">RFC2616</a>] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", <a href="./rfc2616">RFC 2616</a>, June 1999.
[<a id="ref-RFC2743">RFC2743</a>] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", <a href="./rfc2743">RFC 2743</a>, January 2000.
[<a id="ref-RFC3986">RFC3986</a>] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
<a href="./rfc3986">RFC 3986</a>, January 2005.
[<a id="ref-RFC3987">RFC3987</a>] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", <a href="./rfc3987">RFC 3987</a>, January 2005.
[<a id="ref-RFC4422">RFC4422</a>] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", <a href="./rfc4422">RFC 4422</a>, June 2006.
[<a id="ref-RFC5234">RFC5234</a>] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>, January 2008.
[<a id="ref-RFC5246">RFC5246</a>] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", <a href="./rfc5246">RFC 5246</a>, August 2008.
[<a id="ref-RFC5280">RFC5280</a>] 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", <a href="./rfc5280">RFC 5280</a>, May 2008.
[<a id="ref-RFC5587">RFC5587</a>] Williams, N., "Extended Generic Security Service Mechanism
Inquiry APIs", <a href="./rfc5587">RFC 5587</a>, July 2009.
[<a id="ref-RFC5801">RFC5801</a>] 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", <a href="./rfc5801">RFC 5801</a>, July 2010.
[<a id="ref-RFC6125">RFC6125</a>] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", <a href="./rfc6125">RFC 6125</a>, March 2011.
[<a id="ref-SREG1.0">SREG1.0</a>] OpenID Foundation, "OpenID Simple Registration Extension
version 1.0", June 2006, <<a href="http://openid.net/sreg/1.0">http://openid.net/sreg/1.0</a>>.
<span class="grey">Lear, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6616">RFC 6616</a> SASL & GSS-API Mechanism for OpenID May 2012</span>
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-OpReview">OpReview</a>] "Google Sites OpenID Reference Page",
<<a href="http://sites.google.com/site/openidreview/resources">http://sites.google.com/site/openidreview/resources</a>>.
[<a id="ref-RFC1939">RFC1939</a>] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, <a href="./rfc1939">RFC 1939</a>, May 1996.
[<a id="ref-RFC3501">RFC3501</a>] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", <a href="./rfc3501">RFC 3501</a>, March 2003.
[<a id="ref-RFC4959">RFC4959</a>] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for
Simple Authentication and Security Layer (SASL) Initial
Client Response", <a href="./rfc4959">RFC 4959</a>, September 2007.
[<a id="ref-RFC6120">RFC6120</a>] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", <a href="./rfc6120">RFC 6120</a>, March 2011.
[<a id="ref-W3C.REC-html401-19991224">W3C.REC-html401-19991224</a>]
Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium
Recommendation REC-html401-19991224, December 1999,
<<a href="http://www.w3.org/TR/1999/REC-html401-19991224">http://www.w3.org/TR/1999/REC-html401-19991224</a>>.
[<a id="ref-XRI2.0">XRI2.0</a>] Reed, D., Ed. and D. McAlpin, Ed., "Extensible Resource
Identifier (XRI) Syntax V2.0", OASIS Standard xri-syntax-
V2.0-cs, September 2005, <<a href="http://www.oasis-open.org/committees/download.php/15376/xri-syntax-V2.0-cs.html">http://www.oasis-open.org/</a>
<a href="http://www.oasis-open.org/committees/download.php/15376/xri-syntax-V2.0-cs.html">committees/download.php/15376/xri-syntax-V2.0-cs.html</a>>.
<span class="grey">Lear, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6616">RFC 6616</a> SASL & GSS-API Mechanism for OpenID May 2012</span>
Authors' Addresses
Eliot Lear
Cisco Systems GmbH
Richtistrasse 7
CH-8304 Wallisellen
Switzerland
Phone: +41 44 878 9200
EMail: lear@cisco.com
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: <a href="http://www.tschofenig.priv.at">http://www.tschofenig.priv.at</a>
Henry Mauldin
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Phone: +1 (800) 553-6387
EMail: hmauldin@cisco.com
Simon Josefsson
SJD AB
Johan Olof Wallins vag 13
171 64 Solna
Sweden
EMail: simon@josefsson.org
URI: <a href="http://josefsson.org/">http://josefsson.org/</a>
Lear, et al. Standards Track [Page 18]
</pre>
|
