-
Notifications
You must be signed in to change notification settings - Fork 0
/
README
1120 lines (614 loc) · 36.8 KB
/
README
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
Network Working Group N. McCallum
Internet-Draft Red Hat, Inc.
Intended status: Standards Track March 4, 2013
Expires: September 5, 2013
Web Single Sign-On (webSSO)
draft-mccallum-websso-00
Abstract
webSSO is an application-level protocol for decentralized, federated
authentication at the presentation-level. It provides an automated,
stateless technique for obtaining X.509 Client Certificates based
upon a user's authentication credentials.
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 5, 2013.
McCallum Expires September 5, 2013 [Page 1]
Internet-Draft Web Single Sign-On (webSSO) March 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Distinguished Names . . . . . . . . . . . . . . . . . . . 5
2.1.1. webSSOAS Attribute . . . . . . . . . . . . . . . . . . 5
2.1.2. Required Attributes . . . . . . . . . . . . . . . . . 5
2.2. AC Image . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. webSSO Extensions . . . . . . . . . . . . . . . . . . . . 5
2.3.1. webSSOResource Extension . . . . . . . . . . . . . . . 5
2.3.2. webSSODelegate Extension . . . . . . . . . . . . . . . 6
2.3.3. webSSOResourceChain Extension . . . . . . . . . . . . 6
3. Protected Resource . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Extended Validation . . . . . . . . . . . . . . . . . . . 7
3.1.1. Domain Validation . . . . . . . . . . . . . . . . . . 7
3.1.2. Resource Validation . . . . . . . . . . . . . . . . . 7
3.1.3. Revocation Validation . . . . . . . . . . . . . . . . 8
3.2. Additional Resources . . . . . . . . . . . . . . . . . . . 8
4. Authentication Service . . . . . . . . . . . . . . . . . . . . 9
4.1. POST Method . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. DELETE Method . . . . . . . . . . . . . . . . . . . . . . 11
4.3. GET Method . . . . . . . . . . . . . . . . . . . . . . . . 11
5. webSSO Clients . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Certificate Cache . . . . . . . . . . . . . . . . . . . . 12
5.2. Login Process . . . . . . . . . . . . . . . . . . . . . . 12
5.2.1. Using an Existing AC . . . . . . . . . . . . . . . . . 12
5.2.2. Choosing an AS . . . . . . . . . . . . . . . . . . . . 12
5.2.3. Generating the ACR . . . . . . . . . . . . . . . . . . 14
5.2.4. Obtaining a New AC . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
McCallum Expires September 5, 2013 [Page 2]
Internet-Draft Web Single Sign-On (webSSO) March 2013
1. Introduction
1.1. Purpose
webSSO is an application-level protocol for decentralized, federated
authentication at the presentation-level. It provides an automated,
stateless technique for obtaining X.509 Client Certificates based
upon a user's authentication credentials.
webSSO intends to decouple authentication from authorization and to
permit inter-organizational trust of user credentials. It is
designed to deploy on existing TLS enabled protocol stacks,
particularly HTTPS, using pre-existing trust relationships. In
particular, all communication occurs using the client as a proxy,
enabling trust relationships across discreet, disconnected networks.
1.2. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
1.3. Terminology
Protected Resource: The server side of any TLS encrypted connection
which sends a client certificate message. See [RFC5246].
Authentication Service (AS): An HTTP ([RFC2119]) service which
issues X.509 client certificates.
Authentication Service URL (ASURL): The Uniform Resource Locator
where the Authentication Service can be found.
Authentication Certificate (AC): An X.509 client certificate issued
by the Authentication Service.
Authentication Certificate Granting Certificate (ACGC): An
Authentication Certificate issued by the Authentication Service
for itself. It is used to obtain further Authentication
Certificates for other services without re-entering the user's
credentials.
Authentication Certification Request (ACR): A PKCS #10 Certification
Request message [RFC2986] which is POSTed to the ASURL in order to
obtain an AC.
McCallum Expires September 5, 2013 [Page 3]
Internet-Draft Web Single Sign-On (webSSO) March 2013
Delegate Authentication Certification Request (DACR): An ACR wrapped
in a PKCS #7 signature [RFC5652] and signed by the delegate
requesting access.
1.4. Overview
webSSO does not provide authentication directly, but rather is a
policy layer on top of the existing TLS client certificate
authentication ([RFC5246]) and/or HTTP authentication ([RFC2616]).
Without using webSSO, when a Protected Resource requests an X.509
client certificate, obtaining this certificate can be an error-prone
manual process. This typically leads to the issuance of medium- to
long-term client certificates. By contrast, when using webSSO, an
X.509 client certificate can be obtained dynamically, allowing the
conveninece and lower-risk of short-term certificates, called
Authentication Certificates (AC).
The core of webSSO is the Authentication Service (AS). An AS is an
HTTP service which issues client certificates and, optionally,
provides a standard mechanism for revoking issued certificates. The
AS is itself a Protected Resource (PR), allowing the use of an ACGC
to obtain new ACs without re-entering credentials.
Additionally, the client the defined client behavior permits the
seamless location and use of the AS to dynamically allocate
certificates for authentication. Thus, when a client encounters a PR
that it does not have a valid certificate for, it will locate and use
an AS to generate an AC for the PR using an ACGC. If the client does
not have an ACGC for this AS, it will request one from the AS,
authenticating as necessary. Once a client has an ACGC for the AS,
it will use the ACGC to request an AC for the PR. Once the client
possesses a proper AC, it can reauthenticate to the PR without
further contacting the AS until the AC expires or is revoked.
McCallum Expires September 5, 2013 [Page 4]
Internet-Draft Web Single Sign-On (webSSO) March 2013
2. Formatting
2.1. Distinguished Names
2.1.1. webSSOAS Attribute
The webSSOAS attribute is a Subject/Issuer attribute with the OID
1.3.6.1.4.1.2312.10.1. It is a UTF8String which contains an ASURL.
A Subject or Issuer field MUST NOT contain more than one webSSOAS
attribute.
Any certificate used to sign AC's by an AS MUST contain the webSSOAS
attribute in its Subject field.
2.1.2. Required Attributes
In either an AC or an ACR, a Subject MUST contain exactly one UID
attribute and one or more DC attributes as defined in [RFC4514] and
[RFC4519]. Further, the content of these attributes MUST be able to
be expressed in the form of an email address (ex. [email protected])
as defined in [RFC5322].
In an AC, the Issuer field MUST contain the webSSOAS attribute and it
MUST contain the URL used to issue the certificate.
In either an AC or an ACR, the Subject MAY contain other attributes
to be used by the Protected Resource, including custom attributes.
2.2. AC Image
An AC MAY contain one or more images representing the user identified
by the certificate as defined in [RFC6170]. It is RECOMMENDED to use
a photo of the user's face. It is also RECOMMENDED to have the same
image present in two sizes: 48x48 pixels and 128x128 pixels. Using a
smaller color depth is RECOMMENDED to keep certificate size down, so
long as the reduced color depth does not obscure the image.
2.3. webSSO Extensions
2.3.1. webSSOResource Extension
The webSSOResource extension is an X.509 certificate extension of the
X.501 ([X.501]) Name type and with an OID of 1.3.6.1.4.1.2312.10.2.
This extension is used in an AC to identify which PR the AC was
issued for. An AC MUST contain one or more webSSOResource
extensions. An ACR also MUST contain one or more webSSOResource
extensions.
McCallum Expires September 5, 2013 [Page 5]
Internet-Draft Web Single Sign-On (webSSO) March 2013
The extension MUST be marked as critical.
2.3.2. webSSODelegate Extension
The webSSODelegate extension is an X.509 certificate extension of the
X.501 ([X.501]) Name type and with an OID of 1.3.6.1.4.1.2312.10.3.
This extension is used in an AC to identify which delegate the AC was
issued to. An AC MUST NOT contain more than one webSSODelegate
extension.
The extension, when present, MUST be marked as critical.
2.3.3. webSSOResourceChain Extension
The webSSOResourceChain extension is an X.509 certificate extension
of the webSSOIdentity type and with an OID of 1.3.6.1.4.1.2312.10.4.
The extension is used in the ACR to pass the certificate chain of the
PR from the client to the AS for verification. An ACR MUST contain
exactly one webSSOResourceChain extension. The webSSOIdentity type
is defined as:
webSSOIdentity ::= SEQUENCE { cert [0] EXPLICIT Certificate, chain
[1] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
McCallum Expires September 5, 2013 [Page 6]
Internet-Draft Web Single Sign-On (webSSO) March 2013
3. Protected Resource
A Protected Resource (PR) is the server side of any TLS encrypted
connection which sends a client certificate message. The behavior of
a PR is governed by [RFC5246]. However, this section defines an
additional layer of verification to be performed on a webSSO AC to
avoid specific security problems that may arise.
A PR MAY accept traditional X.509 client certificates ([RFC5280]) by
detecting the absense of the webSSOResource extension in the provided
client certificate and bypassing the additional verifications
provided here. This permits the intermixing of traditional X.509
client certificates and webSSO's extended validations ACs in a single
PR.
3.1. Extended Validation
3.1.1. Domain Validation
A PR SHOULD validate the AC to ensure that its issuing AS has
authority to issue ACs for users in the domain listed in the AC's
Subject's DC attributes. Validation is performed by ensuring that
immediate child of the trusted root certificate in the signing chain
contains a critical nameConstraints extension (Section 4.2.1.10 of
[RFC5280]) which contains the domain of the user as expressed in the
DC attributes of the AC's Subject field.
A PR which plans on trusting multiple ASs controlled by different
institutions MUST perform domain validation. Failure to do this will
permit one trusted AS to impersonate a second trusted AS.
An AS MUST perform domain validation.
TODO - Should intermediary certificates also be verified for
nameConstraints?
3.1.2. Resource Validation
A PR SHOULD validate the AC to ensure that the PR's certificate, or
one of its parent certificates, is present in at least one of the
AC's webSSOResource extensions. If this validation fails, the PR
SHOULD reject the AC as invalid.
An AS MUST perform resource validation.
McCallum Expires September 5, 2013 [Page 7]
Internet-Draft Web Single Sign-On (webSSO) March 2013
3.1.3. Revocation Validation
If an AC or any of the certificates in its signing heirarchy have
been configured for either CRL verification (Section 4.2.1.13 of
[RFC5280]) or OCSP ([RFC2560]), the PR SHOULD validate that these
certificates have not been revoked. It is RECOMMENDED that the PR
check an AC for revocation at least every 24 hours and at most every
2 hours. It is RECOMMENDED that non-AC certificates be checked for
revocation once per day.
An AS MUST perform revocation validation.
3.2. Additional Resources
Generally speaking, an AC that will be presented to a PR will be
keyed to the PR's certificate via the webSSOResource extension.
However, in cases where a given PR may be offered across many nodes,
each with their own certificate, it may be desired to key the AC to a
parent certificate rather than each node's individual certificate.
In order to accomplish this, the PR's certificate MAY itself contain
one or more webSSOResource extensions. This identifies to the client
which webSSOResource extensions to place in the ACR. However, any
certificates specified this way MUST be in the signing hierarchy of
the PR's individual certificate.
McCallum Expires September 5, 2013 [Page 8]
Internet-Draft Web Single Sign-On (webSSO) March 2013
4. Authentication Service
An Authentication Service (AS) is an HTTP service available at a URL
called the Authentication Service URL (ASURL). The three HTTP
methods potentially provided by this service are as follows:
o POST - Authenticates a user and issues an AC.
o DELETE - Authenticates a user and revokes ACs.
o GET - Returns a logo for use in visually identifying the AS.
The POST method is REQUIRED. All other methods are OPTIONAL.
However, if the POST method might issue ACs that have a lifespan of
greater than 24 hours, the DELETE method is REQUIRED. This enables
users to revoke long-term certificates that have been compromised.
If a client requests a method that is not supported by the AS, the AS
MUST respond with HTTP status code 405 ("Method Not Allowed") as per
Section 10.4.6 of [RFC2616].
The GET method MAY be exposed outside of a TLS encrypted channel and
MUST NOT require authentication in any form. The POST and DELETE
methods MUST NOT be exposed outside of a TLS encrypted channel and
MUST authenticate the user.
Normally, an AS MUST support authentication via an ACGC and either
traditional X.509 client certificate authentication or HTTP
authentication (ex. Basic, Digest, Kerberos). However, in special
cases, an AS MAY operate in forwarding mode. When an AS operates in
forwarding mode it MUST support using an AC from another AS and MUST
NOT support any other type of authentication. Further, an AS in
forwarding mode MUST close the connection if no client certificate is
received. A single AS MUST NOT attempt to operate in both forwarding
and normal modes.
The method descriptions which appear below (except GET) assume that
proper authentication of the user by the AS has already occurred.
4.1. POST Method
The goal of the POST method is to take an ACR provided in the body of
the HTTP POST request and return a proper AC signifying that the user
specified in the AC has properly authenticated. For an understanding
of the HTTP Status codes specified in this section, see Section 10.4
of [RFC2616].
An AS MUST support two types of data in the POST method body:
application/pkcs10 and application/pkcs7-signature. If any other
McCallum Expires September 5, 2013 [Page 9]
Internet-Draft Web Single Sign-On (webSSO) March 2013
type is presented in the Content-Type HTTP header, the server MUST
return HTTP status code 400 ("Bad Request"). The type application/
pkcs10 indicates that the body contains an ACR. The type
application/pkcs7-signature indicates that the body contains a DACR.
TODO - Should we define new MIME types? This may be particularly
helpful for the DACR.
If the request contains a DACR, the AS MUST validate the delegate's
signature before processing the ACR. If the signature does not
validate, the AS MUST return HTTP status code 403 ("Forbidden").
The AS MUST verify the ACR for the presence of at least one
webSSOResource extension and for exactly one webSSOResourceChain
extension. Futher, the AS MUST verify that the names specified in
the webSSOResource extensions refer to certificates in the
webSSOResourceChain extension. If any of these verifications fail,
the AS MUST return HTTP status code 400 ("Bad Request"). Finally,
the AS MUST validate the certificate chain contained in the
webSSOResourceChain extension. If this validation fails, the AS MUST
return the HTTP status code 403 ("Forbidden").
The AS MAY validate any other field or extension of the ACR and
return appropriate HTTP status codes on failure. However, if during
this OPTIONAL validation, a failure occurs due to violation of an AS
security policy, the AS MUST return HTTP status code 403
("Forbidden").
Once the ACR has passed validation, an AC will be generated. The AC
MUST NOT contain the webSSOResourceChain extension. However, The AC
MUST contain all the webSSOResource extensions copied from the ACR.
The AS MAY choose to copy any data from the ACR into the AC.
Conversely, the AS MAY choose to generate any additional AC data from
scratch or from an internal database and ignore the data contained in
the ACR. However, the AS MUST NOT copy any data into the AC from the
ACR which it cannot internally validate since the resulting AC
represents the canonical information about the user.
If the request contained a DACR, then the Subject field of the
delegate certificate MUST be copied into a webSSODelegate extension
in the AC.
If the AC issued by the AS has a lifespan of more than 24 hours, the
AC MUST include any information required to validate revocation,
either as a cRLDistributionPoints extension (Section 4.2.1.13 of
[RFC5280]) or via OSCP ([RFC2560]).
Upon success, AS MUST return the AC and its entire signing hierarchy
McCallum Expires September 5, 2013 [Page 10]
Internet-Draft Web Single Sign-On (webSSO) March 2013
in the body of the response.
If non-ACGC authentication has been used and the AS is operating in
normal mode, the AS SHOULD only issue ACGCs.
4.2. DELETE Method
The DELETE method is OPTIONAL. However, if the AS is configured to
permit the creation of ACs with a lifespan of more than 24 hours, the
DELETE method MUST be implemented.
The body of the DELETE request MUST contain zero or more comma-
separated AC serial numbers to revoke. When called, the AS MUST
revoke all ACs specified. However, if a DELETE request contains the
serial number of an AC which is owned by another user, the AS MUST
return HTTP status code 403 ("Forbidden"). If no serial numbers are
specified, the AS MUST revoke all ACs issued for the authenticated
user. A revoked AC MUST appear at the cRLDistributionPoints or OCSP
servers within 2 hours. Immediate update is RECOMMENDED.
4.3. GET Method
The GET method is OPTIONAL.
The GET method takes no input and returns a image file with the logo
representing the AS. Using scalable vector image formats is highly
RECOMMENDED.
McCallum Expires September 5, 2013 [Page 11]
Internet-Draft Web Single Sign-On (webSSO) March 2013
5. webSSO Clients
A webSSO client is a standard TLS-enabled client that knows how to
find and use an AS to obtain an Authentication Certificate. In a
normal TLS negotiation, if a CertificateRequest message is sent to
the client, the client will attempt to locate an appropriate
certificate, usually by finding matching certificates in a database
and/or prompting the user. webSSO is best understood from the client
side as an alternative mechanism by which to locate a certificate.
5.1. Certificate Cache
The client MUST maintain a cache of all keypairs generated and all
certificates obtained. This cache MAY be accessable to other clients
run in the same user session. However, it RECOMMENDED to avoid
writing the cache to long-term storage. Further, the client MUST NOT
write the cache to network based storage. Failure to comply with
this requirement provides opportunity for an unpriviledged user to
capture keypairs that travel over the network.
5.2. Login Process
5.2.1. Using an Existing AC
When a CertificateRequest message is received from a PR, the client
MUST first attempt to use a pre-existing AC from the cache. A pre-
existing AC is matched from the cache using the following criteria.
First, the rules defined by Section 7.4.4 of [RFC6170] must be
followed. Second, the AC MUST have the PR's certificiate, or one of
the PR's parent certificates, in one of the AC's webSSOResource
extensions' cert field.
If a matching, non-expired AC is found, it SHOULD be automatically
provided to the PR. In this case no further work is required and the
user SHOULD NOT be prompted. In the case where multiple matching,
non-expired ACs are found, the client MUST choose the one with the
most recent notBefore time.
5.2.2. Choosing an AS
If no matching, non-expired AC was found in the cache, the client
will need to make a decision about which AS to use to obtain an AC
or, alternatively, which traditional client certificate to use. This
decision can in some cases be made automatically. However, in most
cases the user will be prompted.
McCallum Expires September 5, 2013 [Page 12]
Internet-Draft Web Single Sign-On (webSSO) March 2013
5.2.2.1. Automatically Choosing an AS
There are two cases in which an AS can be selected automatically and
the user SHOULD NOT be prompted.
First, if a matching, expired AC is found in the cache, the client
SHOULD use the AS specified in the AC's webSSOAS Issuer attribute.
In the case where multiple matching, expired ACs are found, the
client MUST choose the one with the most recent notBefore time.
Second, if the PR presents only one certificate authority in the
CertificateRequest message and this one certificate authority has the
webSSOAS attribute, the client SHOULD use the AS specified in this
attribute.
5.2.2.2. Manually Choosing an AS
If an AS cannot be chosen automatically, then the client SHOULD
prompt the user identify which AS should be used.
5.2.2.2.1. By Username
The client MUST support specifying AS by username. In this case the
user will be prompted to enter his username in the format of an email
address. The client then MUST perform a DNS TXT record query on the
domain name portion of the username prepended by _websso. The result
of this query is the ASURL to use to authenticate the user.
For example, to authenticate the user [email protected], the
client uses the AS specified in the _websso.example.com TXT record.
5.2.2.2.2. By ACGC
The client SHOULD list the ACGCs in the cache which match the
criteria specified in section 7.4.4 of [RFC6170] since these ACGCs
can be used to obtain a new AC without requiring new credentials.
The client may display any information in the Subject or Issuer
fields of the ACGC. Specifically, displaying images embedded in the
ACGC is RECOMMENDED. Further, the client MAY superimpose the AS logo
(obtained from the ASURL) on top of the certificate image so long as
the certificate image is not obscured.
5.2.2.2.3. By Certificate Authorities
The client SHOULD list the ASs referenced by the webSSOAS attributes
found in the certificate authorities section of the
CertificateRequest message as suggested ASs to use. The client MAY
display any information from the certificate authorities
McCallum Expires September 5, 2013 [Page 13]
Internet-Draft Web Single Sign-On (webSSO) March 2013
DistinguishedNames. Specifically, displaying the AS logo referenced
by the webSSOAS attribute is RECOMMENDED.
5.2.2.2.4. By ASURL
The client MAY permit the user to enter an ASURL manually.
5.2.2.2.5. Traditional Client Certificates
Since webSSO maintains compatibility with traditional client
certificates, webSSO client SHOULD display matching traditional
client certificates in a manner similar to ACGCs, since both can be
selected to provide authentication without requiring any further
credentials.
5.2.3. Generating the ACR
Once the AS is chosen the client MUST generate a new keypair. Using
the public key from the new keypair, the client MUST generate a new
ACR.
If the client does not yet have the username of the user, it SHOULD
prompt the user at this time. The username MUST be converted to the
attribute notation (UID/DC format) and inserted into the Subject
field of the ACR.
Next, the client MUST create the webSSOResourceChain extension in the
ACR containing the full certificate chain of the PR.
Next, the client MUST create a webSSOResource extension containing
the Subject of the PR's certificate. If the PR's certificate
contains any webSSOResource extensions and the Names they contain are
present in the PR's certificate signing hierarchy, they SHOULD be
copied into the ACR. The client MUST NOT copy a Name from the PR
certificate's webSSOResource extension into the ACR if it does not
exist in the PR's certificate hierarchy.
The client MAY specify any other information in the ACR. This
information is a hint only, and the AS MAY reject information it
deems unacceptable.
5.2.4. Obtaining a New AC
Now that the client has the AS, it MUST connect to the AS. If the AS
is not encrypted by TLS, the client MUST NOT use the AS. Futher, if
the certificate used by the AS to encrypt the connection is not
trusted by the client, the client MUST NOT use the AS.
McCallum Expires September 5, 2013 [Page 14]
Internet-Draft Web Single Sign-On (webSSO) March 2013
Since the AS it itself a PR, it will send the CertficateRequest
message as part of the connection process. If the client possesses
an ACGC for this PR, it should automatically provide the ACGC.
Otherwise, it should attempt to conclude negotiation without a client
certificate. If this negotiation fails, the client MUST reconnect
and attempt to find a suitable certificate using the webSSO
methodology recursively.
If an ACGC or other certificate (either webSSO or traditoinal) is
provided to the AS and the connection is established, the client MUST
POST the ACR to the AS. If this suceeds without HTTP authentication,
then the certificate authentication was sufficient to grant an AC.
In this case, the client's task is complete and the resulting AC can
be provided back to the original PR.
However, if the client is presented with HTTP authentication, then
the client MUST attempt to first obtain an ACGC. Thus, the client
MUST then generate a second ACR for the ACGC (see Section 5.2.3).
The client MUST submit this ACR for all future POSTs until the ACGC
is obtained. Once the ACGC is obtained, the client MUST use the ACGC
to submit the original ACR.
Also when presented with HTTP authentication, if the client prompts
the user to enter credentials, if the current connection was
established without a client certificate (webSSO or traditional), the
prompt for HTTP credentials SHOULD offer traditional client
certificate authentication as a secondary option. If the traditional
client certificate option is chosen, the client MUST then renegotiate
TLS, providing the client certificate selected. If the AS still
prompts for the use of HTTP authentication, the client SHOULD prompt
the user for this information again, but exclude the client
certificate option since a client certificate was already selected.
This is to allow for the case of using a traditional client
certificate to obtain a webSSO ACGC.
Once an ACGC is obtained, the client MUST renegotiate the TLS
connection, providing the ACGC, and POST the original ACR, obtaining
an AC for the PR.
McCallum Expires September 5, 2013 [Page 15]
Internet-Draft Web Single Sign-On (webSSO) March 2013
6. Security Considerations
Since webSSO relies heavily on existing standards, the security
considerations from those standards are applicable when they are
used. This is most specifically TLS Client Authentication and HTTP
Authentication.
The most important consideration is that each of the parties in the
transaction are validated via standard certificate validation (and
webSSO extended validation in the case of a PR). The client verifies
the PR and AS by ensuring their certificates are valid and trusted.
When processing a DACR, the delegate is verified as well via the
webSSODelegate extension. The AS verifies the client via either HTTP
Authentication or TLS Client Certificate Authentication. The AS also
verifies the PR and delegate via the webSSOResource and the
webSSODelegate extensions, respectively. The PR establishes a trust
with a given AS by a manual setup process, which may or may not
involve a third-party Certificate Authority. Once this trust is
established, the user trusts ACs issued by the AS. Further, the PR
may also validate the delegate via the webSSODelegate extension. The
end result is that all parties have been verified in every
transaction.
One specific problem that may arise is where a PR trusts either a
public certificate authority or multiple private certificates from
third parties. In this case, two parties can issue a certificate to
the PR for the same domain, allowing one to impersonate the other.
Mitigation of this problem is provided by using the standard
nameConstraints extension.
In order to limit the exposure in the case of a compromised AC, AC's
are always generated to a specific PR. This prevents a certificate
issued for one service to be used for other services, and most
specifically prevents a normal AC from being used as an ACGC to
obtain further certificates.
McCallum Expires September 5, 2013 [Page 16]
Internet-Draft Web Single Sign-On (webSSO) March 2013
7. IANA Considerations
This section needs to be filled in once standard OIDs are selected
for the webSSO attributes and extensions.
McCallum Expires September 5, 2013 [Page 17]
Internet-Draft Web Single Sign-On (webSSO) March 2013
8. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystk, H., Masinter,
L., Leach, P., and T. Berners-Lee, "Hypertext Transfer
Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification - Version 1.7", RFC 2986,
November 2000.
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names",
RFC 4514, June 2006.
[RFC4519] Sciberras, A., "Lightweight Directory Access Protocol
(LDAP): Schema for User Applications", RFC 4519,
June 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol - Version 1.2", RFC 5246, August 2008.
[RFC5280] 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", RFC 5280, May 2008.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
October 2008.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 5652, September 2009.
[RFC6170] Santesson, S., Housley, R., Bajaj, S., and L. Rosenthol,
"Internet X.509 Public Key Infrastructure -- Certificate
Image", RFC 6170, May 2011.
[X.501] CCITT, "Recommendation X.501: The Directory - Models",
1988.