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. jdoe@example.com) 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 michelle@example.com, 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. McCallum Expires September 5, 2013 [Page 18] Internet-Draft Web Single Sign-On (webSSO) March 2013 Author's Address Nathaniel P. McCallum Red Hat, Inc. 1801 Varsity Drive Raleigh, NC 27606 US Phone: +1 404 842 5022 Email: npmccallum@redhat.com URI: http://www.redhat.com/ McCallum Expires September 5, 2013 [Page 19] Internet-Draft Web Single Sign-On (webSSO) March 2013 Full Copyright Statement Copyright (C) The IETF Trust (2013). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. McCallum Expires September 5, 2013 [Page 20]