[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Internet Engineering Task Force                                   T. Chu
Internet-Draft                                                M. Hamrick
Intended status: Standards Track                            M. Lentczner
Expires: January 13, 2010                          Linden Research, Inc.
                                                           July 12, 2009


               Open Grid Protocol: Service Establishment
                       draft-hamrick-ogp-auth-01

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 January 13, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   Service establishment in the Open Grid Protocol is the process of
   creating an application layer association between a client



Chu, et al.             Expires January 13, 2010                [Page 1]


Internet-Draft             OGP Authentication                  July 2009


   application and a remote service responsible for managing an end
   entity's identity.  Before a service may be used, the requesting
   party must present credentials, handle any per-entity authentication-
   time maintenance requirements, and request capabilities the client
   intends to use.  Peer hosts to be authenticated include end users and
   remote domain hosts.  Multiple mechanisms are defined for
   authentication, but all authentication and service establishment
   requests follow the same pattern.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  The Service Establishment Pattern  . . . . . . . . . . . . . .  4
     2.1.  Authentication . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Maintenance  . . . . . . . . . . . . . . . . . . . . . . .  6
     2.3.  Capability Request / Provisioning  . . . . . . . . . . . .  7
   3.  Authentication Mechanisms  . . . . . . . . . . . . . . . . . .  8
     3.1.  User Authentication  . . . . . . . . . . . . . . . . . . .  8
       3.1.1.  Preconditions  . . . . . . . . . . . . . . . . . . . .  8
         3.1.1.1.  Client Preconditions . . . . . . . . . . . . . . .  8
         3.1.1.2.  Agent Domain Preconditions . . . . . . . . . . . .  8
       3.1.2.  Postconditions . . . . . . . . . . . . . . . . . . . .  8
         3.1.2.1.  Client Postconditions  . . . . . . . . . . . . . .  8
         3.1.2.2.  Agent Domain Postconditions  . . . . . . . . . . .  9
       3.1.3.  Side Effects . . . . . . . . . . . . . . . . . . . . .  9
       3.1.4.  Sequence of Events . . . . . . . . . . . . . . . . . .  9
     3.2.  Peer Authentication using a TLS Client Certificate . . . . 11
     3.3.  Peer Authentication using OAuth  . . . . . . . . . . . . . 11
   4.  Agent Login (Resource Class) . . . . . . . . . . . . . . . . . 12
     4.1.  Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 12
       4.1.1.  Agent Identifier . . . . . . . . . . . . . . . . . . . 12
       4.1.2.  Account Identifier . . . . . . . . . . . . . . . . . . 12
       4.1.3.  Hashed Password Authenticator  . . . . . . . . . . . . 12
       4.1.4.  Challenge-Response Authenticator . . . . . . . . . . . 12
       4.1.5.  PKCS#5 PBKDF2 Authenticator  . . . . . . . . . . . . . 13
     4.2.  Response . . . . . . . . . . . . . . . . . . . . . . . . . 13
       4.2.1.  Success  . . . . . . . . . . . . . . . . . . . . . . . 14
       4.2.2.  Maintenance Deferred Success . . . . . . . . . . . . . 14
       4.2.3.  Authentication Non-Success . . . . . . . . . . . . . . 14
     4.3.  Errors and Exceptions  . . . . . . . . . . . . . . . . . . 14
       4.3.1.  Authentication Failure . . . . . . . . . . . . . . . . 14
       4.3.2.  Agent Selection Failure  . . . . . . . . . . . . . . . 14
       4.3.3.  "User Intervention Required" Failure . . . . . . . . . 14
       4.3.4.  "Non Specific" Failure . . . . . . . . . . . . . . . . 15
     4.4.  Interface (POST) . . . . . . . . . . . . . . . . . . . . . 15
   5.  Login-Time Maintenance (Resource Class)  . . . . . . . . . . . 17



Chu, et al.             Expires January 13, 2010                [Page 2]


Internet-Draft             OGP Authentication                  July 2009


     5.1.  Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     5.2.  Response . . . . . . . . . . . . . . . . . . . . . . . . . 17
     5.3.  Interface (GET)  . . . . . . . . . . . . . . . . . . . . . 18
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 20
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20









































Chu, et al.             Expires January 13, 2010                [Page 3]


Internet-Draft             OGP Authentication                  July 2009


1.  Introduction

   The "service establishment pattern" is an abstract sequence used to
   describe the process of creating an application layer association
   between a client application and a service implementing some aspect
   of the virtual world.  There are three steps in service
   establishment: authentication, maintenance and capability request /
   provisioning.  Several mechanisms for authenticating application
   layer entities are defined.  Maintenance is an optional step for
   service providers (though client applications MUST support it.)  The
   final step in the service establishment pattern is the client's
   requests for a specific set of capabilities to perform actions on
   sensitive resources and the service's grant of those capabilities.

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 [RFC2119].


2.  The Service Establishment Pattern

   Three scenarios exist for sensitive resource access in the virtual
   world:

   o  A user presents credentials to an agent domain to demonstrate
      their right to control a specific avatar.

   o  A domain requests general access to services offered by a peer
      domain.

   o  And a domain requests access to a sensitive resource owned by a
      user, maintained by a peer domain.

   The three common service establishment steps are present in each of
   these scenarios: authentication, maintenance and capability request /
   provisioning.

2.1.  Authentication

   Authentication is the first step in associating a client application
   with a service.  Before a client may interact with a remote service,
   it must authenticate itself by presenting credentials demonstrating
   its right to access sensitive resources maintained by the service.
   Authentication is the process of presenting the client's "Identifier"
   and "Authenticator" to the service.




Chu, et al.             Expires January 13, 2010                [Page 4]


Internet-Draft             OGP Authentication                  July 2009


   It should be noted that a remote service may maintain public, non-
   sensitive resources.  "Authentication" in this case is still
   required, if for no other reason than to establish a unique
   application layer session.  If a client requests access to non-
   sensitive information, the server MAY choose to ignore the
   authenticator presented in the authentication phase.

   Authentication begins by requesting the agent_login resource from a
   well-known URL.  [I-D.hamrick-llsd] The service managing this
   resource then makes an access control decision based on the verity of
   the credential The result of this authentication, whether success or
   failure, it is returned to the client application via a LLSD message.
   The content and form of these messages are provided below as an LLIDL
   interface.

   The client authentication process results in one of seven classes of
   response from the service:

   o  success

   o  deferred success due to maintenance

   o  authentication non-success due to missing secret

   o  authentication failure

   o  agent selection failure

   o  "user intervention required" failure, and

   o  "non-specified" failure.

   Responses to authentication requests are successes, non-successes and
   failures.  A "success" indicates the client application should have
   enough information to progress past the authentication phase and
   begin using the service.  A "deferred success" implies use of the
   system will continue after a "short" period.  In either case, the
   agent domain does not expect the client application to re-submit the
   agent_login request.  Authentication "non-success" results from a
   client requesting per-agent or per-account authentication parameters.
   After sending a "non-success", the agent domain expects the client to
   resubmit the agent_login request "shortly."  Failures of all type
   indicate the agent domain believes a condition exists requiring
   explicit user intervention.  In the case of an authentication
   failure, the user should either retry the authentication request or
   recover their password.  A failure due to "user intervention
   required" indicates the agent domain believes the user's account is
   in a state that required "out of band" recovery.  Reading and



Chu, et al.             Expires January 13, 2010                [Page 5]


Internet-Draft             OGP Authentication                  July 2009


   accepting the agent domain's Terms of Service or Critical Messages
   are examples of recovering from "user intervention required"
   failures.  Non-Specified failures indicate a non-recoverable problem
   that is not defined in this specification.

   Client applications may authenticate using an "Account Identifier" or
   an "Agent Identifier".  Either type of identifier may be used for
   authentication.  A service responding to user authentication requests
   (i.e - an "agent domain") MUST support one of the two types of
   identifiers, and MAY support both.  Client applications SHOULD
   support both identifier types.

   An "Account" is an administrative object holding one or more
   references to an "Agent."  This is advantageous in situations where:

   1.  The agent domain does not wish to use an agent first name and
       last name to identify a user, but wishes to use another
       identifier (such as an email address or account number,) or

   2.  The agent domain wishes to allow users with several agents to
       authenticate with the same authenticator, freeing them from the
       requirement of memorizing each individual agent authenticator.

   3.  It is the peer that is being authenticated, not an end user (this
       occurs when domains must authenticate themselves to each other.)

   Please note this spec does not imply a structure to the account
   identifier.  Though an agent domain may use an email address as an
   account identifier, the protocol does not require it and treats the
   identifier simply as an opaque sequence of octets.

   This revision of the Open Grid Protocol defines, but does not require
   the use of, three mechanisms for entity authentication: hashed
   password, challenge-response and PKCS#5 Key Derivation 2.

   Following successful authentication, the service will provide the
   client with either a "maintenance capability" consumed in the
   maintenance step documented below or a "seed capability" consumed in
   the capability request / provisioning step (also described below.)

2.2.  Maintenance

   A service has the option of performing "per-client, authentication-
   time maintenance" as part of the authentication sequence.  Performing
   maintenance after a client is authenticated and before a service
   interface is used has several advantages:





Chu, et al.             Expires January 13, 2010                [Page 6]


Internet-Draft             OGP Authentication                  July 2009


   o  it reduces system-wide downtime

   o  it distributes maintenance across time, and

   o  it consumes computational resources only for those clients who use
      the system

   The service signals it is performing maintenance by returning a
   "Maintenance Capability" instead of a seed capability following
   successful authentication.  The maintenance capability represents a
   finite sequence of transactions performed by the service on the
   client's behalf.  It is expected that maintenance is a task that will
   complete in a "tractable" amount of time.

   The maintenance capability may be queried to retrieve information
   about the transactions that are occurring, including:

   o  a textual description of the maintenance being performed

   o  an estimate for how long the maintenance will take to complete

   The service may provide a maintenance capability to the client
   application in response to successful authentication.  This
   capability is communicated as a URI that identifies a resource with
   the LLIDL interface described in the section below.

   The client is expected to query the maintenance capability
   periodically to receive status updates.  Service implementers SHOULD
   provide reasonable and accurate estimates of the time required to
   complete maintenance.  These estimates do not constitute a service
   guarantee, merely a good-faith estimate of maintenance duration.  One
   of three responses will result in accessing a maintenance capability:
   ongoing, next and complete.  An "ongoing" response indicates the
   server is still working on the same maintenance request, clients MAY
   query the same capability at a later time.  The "next" response
   indicates the server is still performing maintenance, but is
   performing a different task than described in the previous
   capability.  A complete "response" indicates that maintenance is
   finished.  This response type contains a seed capability used in the
   next phase of service establishment.

2.3.  Capability Request / Provisioning

   Following authentication and the optional maintenance step of service
   establishment, the client requests capabilities representing specific
   resources from the server via the "seed capability" returned in the
   authentication or maintenance steps described above.  Seed
   capabilities and capabilities in general are define in the OGP :



Chu, et al.             Expires January 13, 2010                [Page 7]


Internet-Draft             OGP Authentication                  July 2009


   Foundation [I-D.hamrick-llsd] document.


3.  Authentication Mechanisms

3.1.  User Authentication

   Each Agent Domain MUST have a well known and published authentication
   URL.  The Second Life agent domain authentication URL is:
   https://login.agni.secondlife.com/cgi-bin/auth.cgi

3.1.1.  Preconditions

3.1.1.1.  Client Preconditions

   It is generally assumed that before a user attempts to log into an
   agent domain, they will not be actively connected to that agent
   domain.

   It is also assumed that the user has registered their account and/or
   agent; user registration is outside the scope of this specification.

   The client application SHOULD present the agent domain's Terms of
   Service and Critical Messages and allow a user to accept or decline
   them prior to attempting to authenticate.

3.1.1.2.  Agent Domain Preconditions

   If the agent domain requires users to read and agree to the Terms of
   Service or acknowledge receipt of Critical Messages prior to
   authentication, it must maintain a record of which accounts and
   agents have accepted and acknowledged these items.

   Agent domains that support the concept of "suspension" or
   "disablement" should also maintain a record of which accounts and
   agents are suspended or disabled.

3.1.2.  Postconditions

3.1.2.1.  Client Postconditions

   Following successful authentication, the client application SHOULD
   note that the agent has been authenticated to the agent domain.  The
   Open Grid Protocol is NOT stateless.







Chu, et al.             Expires January 13, 2010                [Page 8]


Internet-Draft             OGP Authentication                  July 2009


3.1.2.2.  Agent Domain Postconditions

   After an agent (or account) is authenticated, a seed capability is
   allocated for the agent.  The agent domain SHOULD maintain the
   association between agent credentials (first_name and last_name) and
   the seed capability so it may be re-used if the client attempts to
   re-authenticate the user.

3.1.3.  Side Effects

   The agent domain SHOULD maintain the "presence" state of an agent.
   This state should include the agent's seed capability.  If a
   previously authenticated and "present" agent re-authenticates
   successfully, the agent domain MAY return the same seed capability.

   After successful authentication, it is expected that the client will
   issue another request against the seed capability.  To defend against
   potential Denial of Service attacks against the agent domain, the
   agent domain MAY define a timeout period for the seed capability.  If
   the timeout period expires without a request being made against the
   seed capability, that seed capability will expire.  Successful
   authentication of an agent who is "not present" has the effect of
   starting this timer.

   The Challenge-Response Authenticator is intended to be used with a
   new, randomly generated salt for each authentication request.  If the
   agent domain supports the Challenge-Response authentication scheme,
   it must maintain the "most recently generated salt" for some period
   of time (generally until the expiration of the duration period given
   in the authentication non-success response.)

   After the salt has "timed out" following an unsuccessful Challenge-
   Response authentication request, the agent domain MUST NOT allow the
   use of a previous or fixed salt value.  That is, it is not correct,
   after the salt has expired, to use a null, fixed or previous salt.
   The agent domain MUST generate a new salt and return it to the client
   application.  An unsuccessful authentication request with the
   Challenge-Response scheme also has the side effect of starting the
   salt duration timer.  When this timer expires, the agent domain MUST
   NOT allow authentication with previously generated salts.

3.1.4.  Sequence of Events

   It is possible for an authentication request to occur in conditions
   where multiple errors or exceptions COULD be returned.  As the
   protocol does not support reporting multiple failure conditions, the
   following sequence is provided to determine the priority of failure
   conditions.  This sequence of events is motivated by the following



Chu, et al.             Expires January 13, 2010                [Page 9]


Internet-Draft             OGP Authentication                  July 2009


   principles:

   o  The agent domain should leak no account status information to an
      unauthenticated user.

   o  Maintenance should occur after successful authentication and
      before account status checking in case maintenance involves the
      representation of these states by the agent domain.

   o  The agent domain should check for "administrative issues" after
      maintenance is complete.

   The sequence for authentication is as follows.  At the first error,
   the system produces an appropriate error response.

   1.  If the authenticator provided is a Challenge-Response or PKCS#5
       PBKDF2 type AND a secret is not included, the system returns an
       authentication non-success response.

   2.  The secret and optional authentication parameters are used to
       verify the client is in possession of the shared secret.  If
       authentication is unsuccessful, an authentication failure
       response is returned.

   3.  If per-user login-time maintenance must be performed, the agent
       domain allocates a maintenance capability and returns it to the
       client application as a maintenance deferred success response.

   4.  If an account credential was used for authentication and the
       account "contains" two or more agents and the client application
       did not provide the first_name and last_name of the agent to log
       in as, generate a list of all agents associated with this account
       and return an agent selection failure response.

   5.  If an "administrative issue" exists such as the user is
       suspended, banned, must agree to the terms of service or read
       critical messages, the system returns a "user intervention
       required" response, providing a URL referencing a web resource
       explaining the administrative issue and describing remediation
       steps.

   6.  Check to see if the authenticated agent is associated with an
       agent seed capability already.  If so, return a success response
       referencing that seed capability.

   7.  Start the seed capability timer.  Allocate an agent seed
       capability and return it to the client application via a success
       response.



Chu, et al.             Expires January 13, 2010               [Page 10]


Internet-Draft             OGP Authentication                  July 2009


3.2.  Peer Authentication using a TLS Client Certificate

   In some cases, it may be advantageous to use an aspect of the
   underlying transport to establish the client's identity.  This
   section describes a mechanism for interpreting identity information
   inside a TLS client certificate [RFC5246] for the purpose of OGP
   service establishment.

   The use of TLS client certificates to authenticate the identity of
   the client SHOULD be limited to situations other than user
   authentication.  It is included here as an option for establishing
   inter-domain trust amongst server processes.

   The inputs, outputs and side effects for peer authentication using a
   TLS Client Certificate are the same as those for User Authentication
   save the requirement that a user authenticator need not be provided.
   Strictly speaking, a user identifier is also not required, but SHOULD
   be included in cases where the subject name inside the leaf
   certificate of the client certificate chain does not adequately
   identify the client.

   In practical terms this implies agent_login resources exposed for the
   purpose of peer authentication MUST NOT require the client to include
   the authenticator clause in the LLIDL description of the agent_login
   resource defined below.  Additionally, they MAY choose to ignore the
   contents of the identifier clause defined below, using identity
   information derived from the client certificate chain.  Service
   implementers are strongly cautioned that doing so may limit the
   applicability of their service in environments where distinct
   services with different trust characteristics are deployed on the
   same host, using the same client certificate.

3.3.  Peer Authentication using OAuth

   The OAuth Protocol: Web Delegation [I-D.ietf-oauth-web-delegation]
   draft describes a mechanism for deferring access control
   authorization decisions to a third party.  A service may expose an
   interface capable of receiving a token defined in OAuth Protocol :
   Authentication [I-D.ietf-oauth-authentication].  Clients accessing
   such a service need not provide an identifier or a credential; it is
   assumed that the owner of the resources being accessed has already
   authorized access by the client (as evidenced by valid OAuth tokens.)

   Conforming clients must still correctly consume responses from the
   service including both maintenance and seed capabilities.






Chu, et al.             Expires January 13, 2010               [Page 11]


Internet-Draft             OGP Authentication                  July 2009


4.  Agent Login (Resource Class)

4.1.  Inputs

   LLIDL descriptions are provided below for both agent identifiers and
   account identifiers.  Client applications may use either as the basis
   for authentication.

4.1.1.  Agent Identifier

   An agent identifier contains the first and last name of an agent.

4.1.2.  Account Identifier

   An account identifier must contain the account_name key.  This is the
   opaque sequence of octets used by the agent domain to identify the
   user.  If an account is associated with multiple agents, the client
   application SHOULD include the first_name and last_name of the agent
   the user wishes to use.

4.1.3.  Hashed Password Authenticator

   When a hashed password is used as an authenticator, the string '$1$'
   is prepended to the UTF-8 encoding of the password and processed with
   the MD5 cryptographic hash function.  [RFC1321] This revision of the
   Open Grid Protocol specification requires the use of MD5 with the
   hashed password authenticator.  It also requires the presence of the
   algorithm key, and that the value of this key be the string 'md5'.
   Note that future versions of this specification may ALLOW or REQUIRE
   the use of other cryptographic hash functions.

4.1.4.  Challenge-Response Authenticator

   The Challenge-Response scheme allows the agent domain to select a
   session specific "Salt" to be used in conjunction with the user's
   password to generate an authenticator.  In this scheme the
   authenticator is the hash of the salt prepended to the hash of '$1$'
   prepended to the password.  This revision of the Open Grid Protocol
   specification requires the use of SHA256 with the challenge-response
   authenticator. [sha256] It also requires the presence of the
   algorithm key, and that the value of this key be the string 'sha256'.
   Note that future versions of this specification may ALLOW or REQUIRE
   the use of other cryptographic hash functions.

   To retrieve a session specific salt for use with the Challenge-
   Response authentication scheme from the agent domain, the client
   application sends a login request with a Challenge-Response
   authenticator without the secret item.  If the agent domain supports



Chu, et al.             Expires January 13, 2010               [Page 12]


Internet-Draft             OGP Authentication                  July 2009


   this authenticator, it MUST respond with a 'key' condition including
   a salt and MAY include a duration in the response.  If the duration
   is present, it denotes the number of seconds for which the salt will
   be valid.

      The Challenge-Response Authentication Scheme is not currently
      deployed on the Second Life Grid.

4.1.5.  PKCS#5 PBKDF2 Authenticator

   The PKCS#5 PBKDF2 authenticator is an implementation of RSA Labs'
   Public Key Cryptographic Standards #5 v2.1 Password Based Key
   Derivation Function #2. [pkcs5] In this scheme, the hash of the
   string '$1$' prepended to the password is used in conjunction with a
   salt, iteration count and hash function to generate an authenticator.
   This revision of the Open Grid Protocol specification requires the
   use of SHA256 with the PKCS#5 PBKDS2 authenticator.  It also requires
   the presence of the algorithm key, and that the value of this key be
   the string 'sha256'.  Note that future versions of this specification
   may ALLOW or REQUIRE the use of other cryptographic hash functions.

   As with the Challenge-Response authenticator, the agent domain MUST
   include the salt and iteration count in its response to an
   authentication request that is made without a secret item.
   Conforming agent domains may include a duration in their response
   indicating the number of seconds for which the salt and iteration
   count will be valid.

      The PKCS#5 PBKDF2 Authentication Scheme is not currently deployed
      on the Second Life Grid.

4.2.  Response

   The response to the agent login message is notice of one of seven
   "conditions":

   o  authentication success

   o  maintenance deferred success

   o  authentication non-success

   o  authentication failure

   o  agent selection failure

   o  "user intervention required" failure, and




Chu, et al.             Expires January 13, 2010               [Page 13]


Internet-Draft             OGP Authentication                  July 2009


   o  "non-specific" failure.

   The specification recognizes three "non-failure" responses:

4.2.1.  Success

   Upon success, the agent domain will respond with a message containing
   the "Agent Seed Capability".  Receipt of this capability indicates
   authentication was successful.  This capability is then used for
   further interactions with the system.

4.2.2.  Maintenance Deferred Success

   This condition indicates per-agent (or per-account) login-time
   maintenance is being performed.  It is not an error.  The response
   includes a maintenance cap the client application should use to get
   information about currently executing maintenance.  For more
   information about maintenance, see the Maintenance section below.

4.2.3.  Authentication Non-Success

   Authentication Non-Success is the response given when a client
   queries the agent domain for agent-specific or account-specific
   authentication parameters.  In that it is the expected response to
   such a query, it is not an error or exception.  But it is not an
   indication of successful authentication.

4.3.  Errors and Exceptions

4.3.1.  Authentication Failure

   An authentication failure indicates the client application did not
   provide enough information to authenticate the account or the agent.

4.3.2.  Agent Selection Failure

   An agent selection failure occurs when an account authentication
   request is ambiguous.  In other words, the account a user has
   attempted to use to log in is associated with more than one agent
   account and the client application did not specify which account to
   use.  The response includes a list of first_name / last_name pairs.
   It is expected that the client application will present this list to
   the user and ask which agent to use.

4.3.3.  "User Intervention Required" Failure

   This error indicates that the agent domain cannot authenticate the
   user for non-technical reasons.  The protocol does not attempt to



Chu, et al.             Expires January 13, 2010               [Page 14]


Internet-Draft             OGP Authentication                  July 2009


   describe why, or imply remediation for this error.  But an agent
   domain that returns this response MUST provide a URL containing a
   message describing the condition leading to the error and
   remediation, if known.

4.3.4.  "Non Specific" Failure

   This error indicates some other error exists which does not fall into
   one of the previous six conditions.

4.4.  Interface (POST)

   The following text describes the LLIDL description of the agent_login
   messages.
; authenticators

  ; hashed password authenticator

  &authenticator = {
    type: 'hash',           ; identifies this as "hashed" type
    algorithm: 'md5',       ;
    secret: binary          ; hash of salt prepended to the password;
                            ;   s = h( '$1$' | pw )
  }

  ; challenge response style authenticator

  &authenticator = {
    type: 'challenge',      ; identifies this as a "challenge response"
    algorithm: 'sha256',    ;
    salt: binary,           ; optional - default is ( 0x24, 0x31, 0x24 )
    secret: binary          ; hash of the salt prepended to the password
                            ;   s = h( salt | h( '$1$' | pw ) )
  }

  ; PKCS#5 PBKDF2 style authenticator

  &authenticator = {
    type: 'pkcs5pbkdf2',    ; identifies authenticator as PKCS#5 PBKDF2
    algorithm: string,      ; identifier for hash ('md5' or 'sha256')
    salt: binary,           ; optional - default is ( 0x24, 0x31, 0x24 )
    count: integer,         ; optional - 1 used if not present
    secret: binary          ; hash of the salt prepended to the password
                            ; s = pbkdf2( h('$1$' | pw),salt,count,128)
  }

; identifier types




Chu, et al.             Expires January 13, 2010               [Page 15]


Internet-Draft             OGP Authentication                  July 2009


  ; account identifier

  &identifier = {
    type: 'account',        ; identifies this as an "account identifier"
    account_name: string,
    first_name: string,     ; optional - first_name and last_name
    last_name: string,      ; identify agent to log in as for accounts
                            ; with more than one agent
  }

  ; agent identifier

  &identifier = {
    type: 'agent',           ; identifies this as an "agent identifier"
    first_name: string,
    last_name: string,
  }

; request

  &credential = {
    identifier: &identifier,       ; account or agent identifier
    authenticator: &authenticator  ; 'hash', 'challenge'
                                       ;  or 'pkcs5pbkdf2'
  }

; response

  ; successful response

  &response = {
    condition: 'success',
    agent_seed_capability: uri    ; URL of the agent seed cap
  }

  ; authentication failure

  &response = {
    condition: 'key',
    salt: binary,            ; optional - salt for challenge and PKCS5
    count: integer,          ; optional - iteration count for PKCS5
    duration: integer        ; optional - the duration of the validity
                             ; period of salt and count values in
                             ; seconds
  }

  ; maintenance "non success"




Chu, et al.             Expires January 13, 2010               [Page 16]


Internet-Draft             OGP Authentication                  July 2009


  &response = {
    condition: 'maintenance',
    maintenance_capability: uri,  ; URL of the maintenance cap
    completion: integer           ; an estimate for maintenance duration
                                  ; (in seconds)
  }

  ; agent select failure

  &response = {
    condition: 'select',
    agents: [ string, string, ... ]
  }

  ; administrative failure

  &response = {
    condition: 'intervention',
    message: uri                 ; a URI with human-readable text
                                 ; explaining what the user must do to
                                 ; continue
  }

  ; non-specific error

  &response = {
    condition: 'nonspecific',
    message: string              ; a string describing the failure

; resource definition

%%agent_login
->&credential
<-&response


5.  Login-Time Maintenance (Resource Class)

5.1.  Inputs

   There are no parameters to a maintenance capability request.

5.2.  Response

   There are three responses to a maintenance capability: a description
   of ongoing maintenance, a new maintenance capability describing
   another sequence of maintenance transactions, or a seed capability.
   These responses are identified with the condition items: 'ongoing',



Chu, et al.             Expires January 13, 2010               [Page 17]


Internet-Draft             OGP Authentication                  July 2009


   'next' and 'complete'.

   The 'ongoing' response to a maintenance capability request includes a
   simple textual description of the maintenance performed, an estimate
   for how long the maintenance is expected to take, and a validity
   duration for the capability.  The estimate for how long maintenance
   will take is provided so client applications may provide feedback to
   the user.  The validity duration gives the viewer a minimum time
   period the agent domain will maintain the maintenance capability.

   When the agent domain returns a 'next' response, it indicates that
   the current maintenance is complete, but a new maintenance must be
   performed before the agent may be placed into a region.  The 'next'
   response includes the URL of the next maintenance capability as well
   as an integer describing the minimum time period the agent domain
   will maintain the maintenance capability.

   When an agent domain returns a 'complete' response, it indicates that
   all maintenance is complete.  The response includes the agent seed
   capability that may be used to place the user's avatar in a region.
   It also includes an item describing the validity period for the
   current maintenance capability.

5.3.  Interface (GET)

   The following text describes the LLIDL description of the agent_login
   messages.
 &response = {
   condition: 'ongoing',
   description: string,
   duration: integer,          ; seconds before maintenance is complete
 }

 &response = {
   condition: 'next',
   description: string,
   maintenance_capability: uri ; URL for the next maintenance capability
 }

 &response = {
   condition: 'complete',
   agent_seed_capability: uri  ; the agent's seed cap
 }

 %%maintenance
 ->undef
 <-&response




Chu, et al.             Expires January 13, 2010               [Page 18]


Internet-Draft             OGP Authentication                  July 2009


6.  Security Considerations

   RFC 3552 [RFC3552] describes several aspects to use when evaluating
   the security of a specification or implementation.  We believe most
   common security concerns users of this specification will encounter
   are more appropriately considered as transport, network or link layer
   issues.  However, the following "application security" issues should
   be considered.

   The MD5 cryptographic hash functions has been deprecated and SHOULD
   be used only for compatibility with older applications.

   The use of the hashed password authenticator could result in a replay
   attack if not used in conjunction with an appropriate confidentiality
   preserving transport.  Implementations using the hashed password
   authenticator SHOULD utilize appropriate encryption schemes such as
   TLS [RFC5246] or S/MIME [RFC3851].


7.  IANA Considerations

   This document has no actions for IANA.


8.  References

8.1.  Normative References

   [I-D.hamrick-llsd]
              Brashears, A., Hamrick, M., and M. Lentczner, "Linden Lab
              Structured Data", 2008.

   [I-D.ietf-oauth-authentication]
              Hammer-Lahav, E., "The OAuth Protocol: Authentication",
              draft-ietf-oauth-authentication-01 (work in progress),
              July 2009.

   [I-D.ietf-oauth-web-delegation]
              Hammer-Lahav, E., "The OAuth Protocol: Web Delegation",
              draft-ietf-oauth-web-delegation-01 (work in progress),
              July 2009.

   [I-D.lentczner-ogp-base]
              Lentczner, M., "Open Grid Protocol: Foundation",
              draft-lentczner-ogp-base-00 (work in progress),
              March 2009.

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,



Chu, et al.             Expires January 13, 2010               [Page 19]


Internet-Draft             OGP Authentication                  July 2009


              April 1992.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [pkcs5]    Kaliski, B., "PKCS #5: Password-Based Cryptography
              Specification Version 2.0".

   [sha256]   ""Federal Information Processing Standards Publication
              180-2 (+ Change Notice to include SHA-224)".

8.2.  Informative References

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.

   [RFC3851]  Ramsdell, B., "Secure/Multipurpose Internet Mail
              Extensions (S/MIME) Version 3.1 Message Specification",
              RFC 3851, July 2004.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.


Appendix A.  Acknowledgements

   The author gratefully acknowledges the contributions of David Levine
   and John Hurliman whose participation made this document apropos to a
   wider range of use cases than would have originally been the case.


Authors' Addresses

   Tess Chu
   Linden Research, Inc.
   945 Battery St.
   San Francisco, CA  94111
   US

   Phone: +1 415 243 9000
   Email: tess@lindenlab.com









Chu, et al.             Expires January 13, 2010               [Page 20]


Internet-Draft             OGP Authentication                  July 2009


   Meadhbh Siobhan Hamrick
   Linden Research, Inc.
   945 Battery St.
   San Francisco, CA  94111
   US

   Phone: +1 650 283 0344
   Email: infinity@lindenlab.com


   Mark Lentczner
   Linden Research, Inc.
   945 Battery St.
   San Francisco, CA  94111
   US

   Phone: +1 415 243 9000
   Email: zero@lindenlab.com

































Chu, et al.             Expires January 13, 2010               [Page 21]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/