Simple Sign In
draft-szewczyk-ssi-02

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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 22, 2008.

Abstract

Simple Sign In (SSI) is a simple HTTP authentication protocol that serves as a way for people to sign in to many web sites while only having to remember a single login value and a single password. The goal of SSI is to focus more on simplicity, with a level of security that only needs to be within the same league as what currently can be accomplished with the most common authentication schemes.

Table of Contents

1.  Introduction
    1.1.  Requirements Language
2.  Terminology
3.  SSI RESTTA Detail
    3.1.  Application Class
    3.2.  Resources
4.  Protocol Steps
    4.1.  Step 1: Provider Authentication
    4.2.  Step 2: Consumer Session
    4.3.  Step 3: Client Login Request
    4.4.  Step 4: Consumer to Provider
    4.5.  Step 5: Ticket Generation
    4.6.  Step 6: Consumer Authentication
5.  Ticket Specification
    5.1.  ssi Element
    5.2.  loginCode Element
    5.3.  expire Element
    5.4.  consumer Element
    5.5.  clientHash Element
    5.6.  tokenHash Element
    5.7.  tokenVal Element
    5.8.  payload Element
    5.9.  nickname Element sub-element of payload
    5.10.  avatarUri Element sub-element of payload
    5.11.  email Element sub-element of payload
    5.12.  timezone Element sub-element of payload
    5.13.  country Element sub-element of payload
    5.14.  language Element sub-element of payload
6.  Login Codes
7.  Ticket Example
8.  Error Ticket Example
9.  Extending SSI
10.  Security Considerations
11.  References
    11.1.  Normative References
    11.2.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

There are many authentication methods that have emerged as proposed solutions for a "single sign on" for the Internet. The implementation details for such solutions can be complex, and due to many factors the adoption rates for such technologies have been known to be slow.

The simplest and most used authentication schemes currently have an individual submitting a combination of input such as a username and password. This is done via the client (commonly known as a web browser), through an HTML form that is processed on the client into an HTTP POST or GET request. The application that processes the request internally validates the username and password to authenticate the person on the other end. Typically, the application then establishes a session that is verified through HTTP cookies to keep the client authenticated.

However, because the username and password are passed on a channel that is not secure, the security of the authentication cannot be trusted and is left wide open to a variety of attacks. The most commonly implemented solution is to secure the HTTP connection by using HTTPS.

The goal of SSI is to fit into the basic model of such authentication schemes. SSI is meant to be simple, and if additional security is needed it can be accomplished through independent methods such as HTTPS.

1.1.  Requirements Language

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 RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

2.  Terminology

3.  SSI RESTTA Detail

The following section is a RESTTA detail specification. RESTTA is a REST (Fielding, R., “Representational State Transfer (REST),” 2000.) [REST] based methodology for formatting URIs to make remote requests, making it easy for different applications to communicate by using a common set of resource names and inputs. This section defines the resources, inputs, and application class.

3.1.  Application Class

name: ssi

version: 0.2

detail: http://peopletab.com/ssi.html

3.2.  Resources

The following lists the resources associated with the application class.

ticket_gen

The ticket_gen resource is associated with a provider. Its purpose is to validate the client, establish what consumer that the client wishes to login to, and generate and store the data needed to create an authentication ticket. Upon no internal errors, the resource must only be an HTTP redirect that sends the clients to a consumer_auth resource. The ticket_gen resource uses the following inputs:

from_uri

This is the the consumer URI where the client is redirected from to the provider.

nonce_hash

This a hash value of a random value stored with the client's session on the consumer.

hash_func

The default value SHOULD be "sha-1" if no defaultVal is set in the provider RESTTA document. Note: The hash_func names SHOULD match those found in the Hash Function Textual Names Registry.

consumer_auth

The consumer_auth resource is associated with a consumer. Its purpose is to authenticate the client by fetching the authentication ticket and validating it against the client. Upon consuming the ticket the consumer_auth resource should be an HTTP redirect to either an error message or a confirmation message.

ticket_provider

The ticket_provider resource is associated with a provider. Its purpose is to generate a one-use XML (Bray, T., Paoli, P., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (Second Edition),” Ocober 2000.) [XML] document that serves as an authentication ticket, allowing the consumer to verify a person's wish to log in because the person has assumed degree of authority over the provider to generate such tickets. It takes the following inputs:

nonce_value

Random value that previously has been hashed and provided to the ticket_gen as the nonce_hash.

token_hash

If the user has made any prior logins, the ticket_provider must be provided with a current token_hash that the consumer has on record.

4.  Protocol Steps

Prior to beginning a login attempt the person must already be registered with the provider. This registration should use separate credentials than those used to log-in through a consumer.

4.1.  Step 1: Provider Authentication

Before signing into any sites the client MUST first be authenticated with the provider. The implementation details of this step, as well as registration steps are application specific. A session SHOULD be established for the client.

4.2.  Step 2: Consumer Session

The person directs the client to a consumer and the consumer establishes a session for the client. The person is presented with a form that has a login input field.

Login Value Note:

The login value must be in email format, where the value is login_name + "@" + domain.com, as described in RFC 2822 (Resnick, P., “Internet Message Format,” April 2001.) [RFC2822]. However, it SHOULD be assumed that the value is not an actual email address.

4.3.  Step 3: Client Login Request

The person operating the client submits the values to the consumer. The consumer parses the login value to retrieve the domain portion. The consumer makes an HTTP request to the domain to retrieve a RESTTA translation file (Representational State Transfer Translation Actions). Parsing this file allows the consumer to format the URIs needed to communication with the provider.

4.4.  Step 4: Consumer to Provider

The consumer generates a nonce and stores it with the client's session. The nonce is then hashed using the function specified in the RESTTA document. This is then used as the nonce_hash. The consumer then generates the from_uri and the hash_func inputs, storing them as well, and issues an HTTP redirect to the ticket_gen resource.

4.5.  Step 5: Ticket Generation

The ticket_gen authenticates the client. If authenticated, the ticket_gen asks the client to verify the intent to login. The nonce_hash is stored in connection with the user. The provider's ticket_gen then establishes what the consumer_auth URI is through RESTTA, and then issues an HTTP redirect to the consumer_auth.

4.6.  Step 6: Consumer Authentication

The consumer then issues a direct request to the ticket_provider resource, including a token_hash value if the user has made prior logins and a token_hash is on record. The ticket provider verifies the nonce, the existence of the token_hash, and generates a response ticket. If valid, the consumer then authenticates the client and processes the ticket payload. The consumer_auth then redirects the client to the from_uri, indicating whether the login was a success or failure.

5.  Ticket Specification

Authentication tickets are XML (Bray, T., Paoli, P., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (Second Edition),” Ocober 2000.) [XML] documents that give out information on behalf of a client for the purpose of signifying the intent to login to a consumer as well as providing public client details, as well as values that can be used as 'security hints' by the consumer. These tickets should only be generated once per login attempt for each consumer.

This section outlines all the elements, or tags, as well as each element's respective properties. Some tags and properties are required, some are not.

5.1.  ssi Element

The ssi tag is the base tag used to encapsulate the other elements. It is required.

5.2.  loginCode Element

This tag specifies a login code that corresponds to either an OK or an error. It is required.

5.3.  expire Element

The value of this tag is a unix timestamp that serves as an expiration time for the ticket. It is required.

5.4.  consumer Element

The consumer element corresponds to the consumer URI host name that the ticket is intended for. It is required.

5.5.  clientHash Element

The clientHash value is computing the following way: hash_func(client_useragent + client_ip_address). It is required.

5.6.  tokenHash Element

The tokenHash value is computed the following way: generate a new token value and hash_func(token value). The token value MUST be stored for future logins to the same consumer. The provider SHOULD keep a number of these generated hash/value pairs on record to take into account potential ticket timeouts and other errors, and cycle out old values as needed. The recommendation is keeping 3-5 "fresh" pairs on record. The consumer typically only needs to keep a single tokenHash on record per SSI user. This element is required unless the loginCode value corresponds to an error. This tokenHash value is to be provided by the consumer on future logins, indicating the need to generate a new tokenHash, and to provide the tokenValue for the old hash.

5.7.  tokenVal Element

The tokenVal element MUST be the token value used to generate the tokenHash supplied by the consumer. This element is required only if there has been a prior successful login to the consumer and if the loginCode is not an error.

5.8.  payload Element

The payload element encapsulates elements used to describe the person behind the client. All payload sub-elements are optional. The payload element SHOULD not be present if the loginCode element's value is an error.

5.9.  nickname Element sub-element of payload

The value of the nickname element is the person's preferred display name.

5.10.  avatarUri Element sub-element of payload

The value of the avatarUri element is a URI that points to an image that the person wishes to use as an avatar.

5.11.  email Element sub-element of payload

The email element's value is the person's email address in the format described in RFC 2822 (Resnick, P., “Internet Message Format,” April 2001.) [RFC2822]

5.12.  timezone Element sub-element of payload

This element's value is the zoneinfo zone name as found here: List of zoneinfo timezones , which is generated from the official Timezone database.

5.13.  country Element sub-element of payload

This value is the country of residence as specified by ISO-3166-1 Alpha 2.

5.14.  language Element sub-element of payload

The value of this element is the person's language as specified by ISO 639-1.

6.  Login Codes

The following lists the valid login codes for the loginCode element. Only login code 100 does not signify an error.

100

Signifies an OK status meaning that the login procedure has not encountered any errors.

200

Indicates that the ticket_gen resource could not validate the client.

201

Indicates that the client cancelled the login process.

202

Indicates that the ticket_gen resource encountered missing or poorly formatted values.

203

Indicates an unsupported hash function.

300

Indicates an internal application error has occurred.

301

Indicates an invalid nonce value was submitted to the ticket_provider resource.

302

Indicates providing a non-existant or missing tokenHash value.

303

Indicates expecting a tokenHash

7.  Ticket Example

The following is an example SSI ticket:

<?xml version='1.0'?>
<ssi version="0.2">
	<loginCode>100</loginCode>
	<expire>1202803303</expire>
	<consumer>mysite.com</consumer>
	<clientHash hashfunc="sha-1">8639316725bece379d63338db8ba6fcece609819</clientHash>
	<tokenHash hashfunc="sha-1">28d462a25e1af470232eaaa560aad698466f5a41</tokenHash>
	<tokenVal>84d9cfc2f395ce883a41d7ffc1bbcf4e</tokenVal>
	<payload>
		<nickname>Ani</nickname>
		<avatarUri>http://www.avatarity.com/avatars/9/98/9879.jpg</avatarUri>
		<email>darthvader@starwars.com</email>
		<timezone>America/New_York</timezone>
		<country>US</country>
		<language>EN</language>
	</payload>
</ssi>

8.  Error Ticket Example

The following is an example SSI error ticket:

<?xml version='1.0'?>
<ssi version="0.2">
	<loginCode>201</loginCode>
	<expire>1202803303</expire>
	<consumer>mysite.com</consumer>
	<clientHash hashfunc="sha-1">8639316725bece379d63338db8ba6fcece609819</clientHash>
</ssi>

9.  Extending SSI

The primary means to extend SSI is by adding elements to the ticket payload. An SSI ticket may have custom elements, but only if those elements are defined in a namespace. For example:

<payload xmlns:im="http://site.com/spec/im">
	<nickname>Ani</nickname>
	<avatarUri>http://www.avatarity.com/avatars/9/98/9879.jpg</avatarUri>
	<email>darthvader@starwars.com</email>
	<timezone>America/New_York</timezone>
	<country>US</country>
	<language>EN</language>
	<im:aim>vader5000</im:aim>
	<im:yahoo>anakinskywalker@yahoo.com</im:yahoo>
	<im:jabber>anakinskywalker@starwars.com</im:jabber>
</payload>

10.  Security Considerations

It must be noted that the goal of SSI is to only match the functionality of most commonly used authentication systems, which are not known to be secure. SSI is also not meant as a means to establish any sort of trust. However, just as security can be enhanced for common authentication schemes, so can the security of SSI.

Security for SSI can be enhanced through the practice of securing provider resources behind HTTPS through the use of SSL (Freier, A., Karlton, P., and P. Kocher, “The SSL 3.0 Protocol,” November 1996.) [SSL] or TLS (Rescorla, E., “HTTP Over TLS,” May 2000.) [RFC2818]. Otherwise, SSI is susceptible to potential man-in-the-middle attacks or replay attacks. Consumer-level security is more nebulous, and more discerning persons should expect HTTPS for the consumer resources as well.

Furthermore, it must be stressed that even if the ticket_gen and ticket_provider resources are secured through HTTPS, any data transferred with the requests will ultimately be at the consumer's disposal. The degree of trust placed in consumers rests only on the judgment of the person operating the client.

11.  References

11.1. Normative References

11.2. Informative References

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2008).

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.