idnits 2.17.1 draft-hamrick-ogp-auth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2009) is 5402 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.lentczner-ogp-base' is defined on line 857, but no explicit reference was found in the text -- No information found for draft-hamrick-llsd - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.hamrick-llsd' ** Downref: Normative reference to an Informational draft: draft-lentczner-ogp-base (ref. 'I-D.lentczner-ogp-base') ** Downref: Normative reference to an Informational RFC: RFC 1321 -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Chu 3 Internet-Draft M. Hamrick 4 Intended status: Standards Track M. Lentczner 5 Expires: January 13, 2010 Linden Research, Inc. 6 July 12, 2009 8 Open Grid Protocol: Service Establishment 9 draft-hamrick-ogp-auth-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 13, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 Service establishment in the Open Grid Protocol is the process of 48 creating an application layer association between a client 49 application and a remote service responsible for managing an end 50 entity's identity. Before a service may be used, the requesting 51 party must present credentials, handle any per-entity authentication- 52 time maintenance requirements, and request capabilities the client 53 intends to use. Peer hosts to be authenticated include end users and 54 remote domain hosts. Multiple mechanisms are defined for 55 authentication, but all authentication and service establishment 56 requests follow the same pattern. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 62 2. The Service Establishment Pattern . . . . . . . . . . . . . . 4 63 2.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Maintenance . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.3. Capability Request / Provisioning . . . . . . . . . . . . 7 66 3. Authentication Mechanisms . . . . . . . . . . . . . . . . . . 8 67 3.1. User Authentication . . . . . . . . . . . . . . . . . . . 8 68 3.1.1. Preconditions . . . . . . . . . . . . . . . . . . . . 8 69 3.1.1.1. Client Preconditions . . . . . . . . . . . . . . . 8 70 3.1.1.2. Agent Domain Preconditions . . . . . . . . . . . . 8 71 3.1.2. Postconditions . . . . . . . . . . . . . . . . . . . . 8 72 3.1.2.1. Client Postconditions . . . . . . . . . . . . . . 8 73 3.1.2.2. Agent Domain Postconditions . . . . . . . . . . . 9 74 3.1.3. Side Effects . . . . . . . . . . . . . . . . . . . . . 9 75 3.1.4. Sequence of Events . . . . . . . . . . . . . . . . . . 9 76 3.2. Peer Authentication using a TLS Client Certificate . . . . 11 77 3.3. Peer Authentication using OAuth . . . . . . . . . . . . . 11 78 4. Agent Login (Resource Class) . . . . . . . . . . . . . . . . . 12 79 4.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 4.1.1. Agent Identifier . . . . . . . . . . . . . . . . . . . 12 81 4.1.2. Account Identifier . . . . . . . . . . . . . . . . . . 12 82 4.1.3. Hashed Password Authenticator . . . . . . . . . . . . 12 83 4.1.4. Challenge-Response Authenticator . . . . . . . . . . . 12 84 4.1.5. PKCS#5 PBKDF2 Authenticator . . . . . . . . . . . . . 13 85 4.2. Response . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 4.2.1. Success . . . . . . . . . . . . . . . . . . . . . . . 14 87 4.2.2. Maintenance Deferred Success . . . . . . . . . . . . . 14 88 4.2.3. Authentication Non-Success . . . . . . . . . . . . . . 14 89 4.3. Errors and Exceptions . . . . . . . . . . . . . . . . . . 14 90 4.3.1. Authentication Failure . . . . . . . . . . . . . . . . 14 91 4.3.2. Agent Selection Failure . . . . . . . . . . . . . . . 14 92 4.3.3. "User Intervention Required" Failure . . . . . . . . . 14 93 4.3.4. "Non Specific" Failure . . . . . . . . . . . . . . . . 15 94 4.4. Interface (POST) . . . . . . . . . . . . . . . . . . . . . 15 95 5. Login-Time Maintenance (Resource Class) . . . . . . . . . . . 17 96 5.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 5.2. Response . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 5.3. Interface (GET) . . . . . . . . . . . . . . . . . . . . . 18 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 100 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 101 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 102 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 103 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 104 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 107 1. Introduction 109 The "service establishment pattern" is an abstract sequence used to 110 describe the process of creating an application layer association 111 between a client application and a service implementing some aspect 112 of the virtual world. There are three steps in service 113 establishment: authentication, maintenance and capability request / 114 provisioning. Several mechanisms for authenticating application 115 layer entities are defined. Maintenance is an optional step for 116 service providers (though client applications MUST support it.) The 117 final step in the service establishment pattern is the client's 118 requests for a specific set of capabilities to perform actions on 119 sensitive resources and the service's grant of those capabilities. 121 1.1. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 2. The Service Establishment Pattern 129 Three scenarios exist for sensitive resource access in the virtual 130 world: 132 o A user presents credentials to an agent domain to demonstrate 133 their right to control a specific avatar. 135 o A domain requests general access to services offered by a peer 136 domain. 138 o And a domain requests access to a sensitive resource owned by a 139 user, maintained by a peer domain. 141 The three common service establishment steps are present in each of 142 these scenarios: authentication, maintenance and capability request / 143 provisioning. 145 2.1. Authentication 147 Authentication is the first step in associating a client application 148 with a service. Before a client may interact with a remote service, 149 it must authenticate itself by presenting credentials demonstrating 150 its right to access sensitive resources maintained by the service. 151 Authentication is the process of presenting the client's "Identifier" 152 and "Authenticator" to the service. 154 It should be noted that a remote service may maintain public, non- 155 sensitive resources. "Authentication" in this case is still 156 required, if for no other reason than to establish a unique 157 application layer session. If a client requests access to non- 158 sensitive information, the server MAY choose to ignore the 159 authenticator presented in the authentication phase. 161 Authentication begins by requesting the agent_login resource from a 162 well-known URL. [I-D.hamrick-llsd] The service managing this 163 resource then makes an access control decision based on the verity of 164 the credential The result of this authentication, whether success or 165 failure, it is returned to the client application via a LLSD message. 166 The content and form of these messages are provided below as an LLIDL 167 interface. 169 The client authentication process results in one of seven classes of 170 response from the service: 172 o success 174 o deferred success due to maintenance 176 o authentication non-success due to missing secret 178 o authentication failure 180 o agent selection failure 182 o "user intervention required" failure, and 184 o "non-specified" failure. 186 Responses to authentication requests are successes, non-successes and 187 failures. A "success" indicates the client application should have 188 enough information to progress past the authentication phase and 189 begin using the service. A "deferred success" implies use of the 190 system will continue after a "short" period. In either case, the 191 agent domain does not expect the client application to re-submit the 192 agent_login request. Authentication "non-success" results from a 193 client requesting per-agent or per-account authentication parameters. 194 After sending a "non-success", the agent domain expects the client to 195 resubmit the agent_login request "shortly." Failures of all type 196 indicate the agent domain believes a condition exists requiring 197 explicit user intervention. In the case of an authentication 198 failure, the user should either retry the authentication request or 199 recover their password. A failure due to "user intervention 200 required" indicates the agent domain believes the user's account is 201 in a state that required "out of band" recovery. Reading and 202 accepting the agent domain's Terms of Service or Critical Messages 203 are examples of recovering from "user intervention required" 204 failures. Non-Specified failures indicate a non-recoverable problem 205 that is not defined in this specification. 207 Client applications may authenticate using an "Account Identifier" or 208 an "Agent Identifier". Either type of identifier may be used for 209 authentication. A service responding to user authentication requests 210 (i.e - an "agent domain") MUST support one of the two types of 211 identifiers, and MAY support both. Client applications SHOULD 212 support both identifier types. 214 An "Account" is an administrative object holding one or more 215 references to an "Agent." This is advantageous in situations where: 217 1. The agent domain does not wish to use an agent first name and 218 last name to identify a user, but wishes to use another 219 identifier (such as an email address or account number,) or 221 2. The agent domain wishes to allow users with several agents to 222 authenticate with the same authenticator, freeing them from the 223 requirement of memorizing each individual agent authenticator. 225 3. It is the peer that is being authenticated, not an end user (this 226 occurs when domains must authenticate themselves to each other.) 228 Please note this spec does not imply a structure to the account 229 identifier. Though an agent domain may use an email address as an 230 account identifier, the protocol does not require it and treats the 231 identifier simply as an opaque sequence of octets. 233 This revision of the Open Grid Protocol defines, but does not require 234 the use of, three mechanisms for entity authentication: hashed 235 password, challenge-response and PKCS#5 Key Derivation 2. 237 Following successful authentication, the service will provide the 238 client with either a "maintenance capability" consumed in the 239 maintenance step documented below or a "seed capability" consumed in 240 the capability request / provisioning step (also described below.) 242 2.2. Maintenance 244 A service has the option of performing "per-client, authentication- 245 time maintenance" as part of the authentication sequence. Performing 246 maintenance after a client is authenticated and before a service 247 interface is used has several advantages: 249 o it reduces system-wide downtime 251 o it distributes maintenance across time, and 253 o it consumes computational resources only for those clients who use 254 the system 256 The service signals it is performing maintenance by returning a 257 "Maintenance Capability" instead of a seed capability following 258 successful authentication. The maintenance capability represents a 259 finite sequence of transactions performed by the service on the 260 client's behalf. It is expected that maintenance is a task that will 261 complete in a "tractable" amount of time. 263 The maintenance capability may be queried to retrieve information 264 about the transactions that are occurring, including: 266 o a textual description of the maintenance being performed 268 o an estimate for how long the maintenance will take to complete 270 The service may provide a maintenance capability to the client 271 application in response to successful authentication. This 272 capability is communicated as a URI that identifies a resource with 273 the LLIDL interface described in the section below. 275 The client is expected to query the maintenance capability 276 periodically to receive status updates. Service implementers SHOULD 277 provide reasonable and accurate estimates of the time required to 278 complete maintenance. These estimates do not constitute a service 279 guarantee, merely a good-faith estimate of maintenance duration. One 280 of three responses will result in accessing a maintenance capability: 281 ongoing, next and complete. An "ongoing" response indicates the 282 server is still working on the same maintenance request, clients MAY 283 query the same capability at a later time. The "next" response 284 indicates the server is still performing maintenance, but is 285 performing a different task than described in the previous 286 capability. A complete "response" indicates that maintenance is 287 finished. This response type contains a seed capability used in the 288 next phase of service establishment. 290 2.3. Capability Request / Provisioning 292 Following authentication and the optional maintenance step of service 293 establishment, the client requests capabilities representing specific 294 resources from the server via the "seed capability" returned in the 295 authentication or maintenance steps described above. Seed 296 capabilities and capabilities in general are define in the OGP : 298 Foundation [I-D.hamrick-llsd] document. 300 3. Authentication Mechanisms 302 3.1. User Authentication 304 Each Agent Domain MUST have a well known and published authentication 305 URL. The Second Life agent domain authentication URL is: 306 https://login.agni.secondlife.com/cgi-bin/auth.cgi 308 3.1.1. Preconditions 310 3.1.1.1. Client Preconditions 312 It is generally assumed that before a user attempts to log into an 313 agent domain, they will not be actively connected to that agent 314 domain. 316 It is also assumed that the user has registered their account and/or 317 agent; user registration is outside the scope of this specification. 319 The client application SHOULD present the agent domain's Terms of 320 Service and Critical Messages and allow a user to accept or decline 321 them prior to attempting to authenticate. 323 3.1.1.2. Agent Domain Preconditions 325 If the agent domain requires users to read and agree to the Terms of 326 Service or acknowledge receipt of Critical Messages prior to 327 authentication, it must maintain a record of which accounts and 328 agents have accepted and acknowledged these items. 330 Agent domains that support the concept of "suspension" or 331 "disablement" should also maintain a record of which accounts and 332 agents are suspended or disabled. 334 3.1.2. Postconditions 336 3.1.2.1. Client Postconditions 338 Following successful authentication, the client application SHOULD 339 note that the agent has been authenticated to the agent domain. The 340 Open Grid Protocol is NOT stateless. 342 3.1.2.2. Agent Domain Postconditions 344 After an agent (or account) is authenticated, a seed capability is 345 allocated for the agent. The agent domain SHOULD maintain the 346 association between agent credentials (first_name and last_name) and 347 the seed capability so it may be re-used if the client attempts to 348 re-authenticate the user. 350 3.1.3. Side Effects 352 The agent domain SHOULD maintain the "presence" state of an agent. 353 This state should include the agent's seed capability. If a 354 previously authenticated and "present" agent re-authenticates 355 successfully, the agent domain MAY return the same seed capability. 357 After successful authentication, it is expected that the client will 358 issue another request against the seed capability. To defend against 359 potential Denial of Service attacks against the agent domain, the 360 agent domain MAY define a timeout period for the seed capability. If 361 the timeout period expires without a request being made against the 362 seed capability, that seed capability will expire. Successful 363 authentication of an agent who is "not present" has the effect of 364 starting this timer. 366 The Challenge-Response Authenticator is intended to be used with a 367 new, randomly generated salt for each authentication request. If the 368 agent domain supports the Challenge-Response authentication scheme, 369 it must maintain the "most recently generated salt" for some period 370 of time (generally until the expiration of the duration period given 371 in the authentication non-success response.) 373 After the salt has "timed out" following an unsuccessful Challenge- 374 Response authentication request, the agent domain MUST NOT allow the 375 use of a previous or fixed salt value. That is, it is not correct, 376 after the salt has expired, to use a null, fixed or previous salt. 377 The agent domain MUST generate a new salt and return it to the client 378 application. An unsuccessful authentication request with the 379 Challenge-Response scheme also has the side effect of starting the 380 salt duration timer. When this timer expires, the agent domain MUST 381 NOT allow authentication with previously generated salts. 383 3.1.4. Sequence of Events 385 It is possible for an authentication request to occur in conditions 386 where multiple errors or exceptions COULD be returned. As the 387 protocol does not support reporting multiple failure conditions, the 388 following sequence is provided to determine the priority of failure 389 conditions. This sequence of events is motivated by the following 390 principles: 392 o The agent domain should leak no account status information to an 393 unauthenticated user. 395 o Maintenance should occur after successful authentication and 396 before account status checking in case maintenance involves the 397 representation of these states by the agent domain. 399 o The agent domain should check for "administrative issues" after 400 maintenance is complete. 402 The sequence for authentication is as follows. At the first error, 403 the system produces an appropriate error response. 405 1. If the authenticator provided is a Challenge-Response or PKCS#5 406 PBKDF2 type AND a secret is not included, the system returns an 407 authentication non-success response. 409 2. The secret and optional authentication parameters are used to 410 verify the client is in possession of the shared secret. If 411 authentication is unsuccessful, an authentication failure 412 response is returned. 414 3. If per-user login-time maintenance must be performed, the agent 415 domain allocates a maintenance capability and returns it to the 416 client application as a maintenance deferred success response. 418 4. If an account credential was used for authentication and the 419 account "contains" two or more agents and the client application 420 did not provide the first_name and last_name of the agent to log 421 in as, generate a list of all agents associated with this account 422 and return an agent selection failure response. 424 5. If an "administrative issue" exists such as the user is 425 suspended, banned, must agree to the terms of service or read 426 critical messages, the system returns a "user intervention 427 required" response, providing a URL referencing a web resource 428 explaining the administrative issue and describing remediation 429 steps. 431 6. Check to see if the authenticated agent is associated with an 432 agent seed capability already. If so, return a success response 433 referencing that seed capability. 435 7. Start the seed capability timer. Allocate an agent seed 436 capability and return it to the client application via a success 437 response. 439 3.2. Peer Authentication using a TLS Client Certificate 441 In some cases, it may be advantageous to use an aspect of the 442 underlying transport to establish the client's identity. This 443 section describes a mechanism for interpreting identity information 444 inside a TLS client certificate [RFC5246] for the purpose of OGP 445 service establishment. 447 The use of TLS client certificates to authenticate the identity of 448 the client SHOULD be limited to situations other than user 449 authentication. It is included here as an option for establishing 450 inter-domain trust amongst server processes. 452 The inputs, outputs and side effects for peer authentication using a 453 TLS Client Certificate are the same as those for User Authentication 454 save the requirement that a user authenticator need not be provided. 455 Strictly speaking, a user identifier is also not required, but SHOULD 456 be included in cases where the subject name inside the leaf 457 certificate of the client certificate chain does not adequately 458 identify the client. 460 In practical terms this implies agent_login resources exposed for the 461 purpose of peer authentication MUST NOT require the client to include 462 the authenticator clause in the LLIDL description of the agent_login 463 resource defined below. Additionally, they MAY choose to ignore the 464 contents of the identifier clause defined below, using identity 465 information derived from the client certificate chain. Service 466 implementers are strongly cautioned that doing so may limit the 467 applicability of their service in environments where distinct 468 services with different trust characteristics are deployed on the 469 same host, using the same client certificate. 471 3.3. Peer Authentication using OAuth 473 The OAuth Protocol: Web Delegation [I-D.ietf-oauth-web-delegation] 474 draft describes a mechanism for deferring access control 475 authorization decisions to a third party. A service may expose an 476 interface capable of receiving a token defined in OAuth Protocol : 477 Authentication [I-D.ietf-oauth-authentication]. Clients accessing 478 such a service need not provide an identifier or a credential; it is 479 assumed that the owner of the resources being accessed has already 480 authorized access by the client (as evidenced by valid OAuth tokens.) 482 Conforming clients must still correctly consume responses from the 483 service including both maintenance and seed capabilities. 485 4. Agent Login (Resource Class) 487 4.1. Inputs 489 LLIDL descriptions are provided below for both agent identifiers and 490 account identifiers. Client applications may use either as the basis 491 for authentication. 493 4.1.1. Agent Identifier 495 An agent identifier contains the first and last name of an agent. 497 4.1.2. Account Identifier 499 An account identifier must contain the account_name key. This is the 500 opaque sequence of octets used by the agent domain to identify the 501 user. If an account is associated with multiple agents, the client 502 application SHOULD include the first_name and last_name of the agent 503 the user wishes to use. 505 4.1.3. Hashed Password Authenticator 507 When a hashed password is used as an authenticator, the string '$1$' 508 is prepended to the UTF-8 encoding of the password and processed with 509 the MD5 cryptographic hash function. [RFC1321] This revision of the 510 Open Grid Protocol specification requires the use of MD5 with the 511 hashed password authenticator. It also requires the presence of the 512 algorithm key, and that the value of this key be the string 'md5'. 513 Note that future versions of this specification may ALLOW or REQUIRE 514 the use of other cryptographic hash functions. 516 4.1.4. Challenge-Response Authenticator 518 The Challenge-Response scheme allows the agent domain to select a 519 session specific "Salt" to be used in conjunction with the user's 520 password to generate an authenticator. In this scheme the 521 authenticator is the hash of the salt prepended to the hash of '$1$' 522 prepended to the password. This revision of the Open Grid Protocol 523 specification requires the use of SHA256 with the challenge-response 524 authenticator. [sha256] It also requires the presence of the 525 algorithm key, and that the value of this key be the string 'sha256'. 526 Note that future versions of this specification may ALLOW or REQUIRE 527 the use of other cryptographic hash functions. 529 To retrieve a session specific salt for use with the Challenge- 530 Response authentication scheme from the agent domain, the client 531 application sends a login request with a Challenge-Response 532 authenticator without the secret item. If the agent domain supports 533 this authenticator, it MUST respond with a 'key' condition including 534 a salt and MAY include a duration in the response. If the duration 535 is present, it denotes the number of seconds for which the salt will 536 be valid. 538 The Challenge-Response Authentication Scheme is not currently 539 deployed on the Second Life Grid. 541 4.1.5. PKCS#5 PBKDF2 Authenticator 543 The PKCS#5 PBKDF2 authenticator is an implementation of RSA Labs' 544 Public Key Cryptographic Standards #5 v2.1 Password Based Key 545 Derivation Function #2. [pkcs5] In this scheme, the hash of the 546 string '$1$' prepended to the password is used in conjunction with a 547 salt, iteration count and hash function to generate an authenticator. 548 This revision of the Open Grid Protocol specification requires the 549 use of SHA256 with the PKCS#5 PBKDS2 authenticator. It also requires 550 the presence of the algorithm key, and that the value of this key be 551 the string 'sha256'. Note that future versions of this specification 552 may ALLOW or REQUIRE the use of other cryptographic hash functions. 554 As with the Challenge-Response authenticator, the agent domain MUST 555 include the salt and iteration count in its response to an 556 authentication request that is made without a secret item. 557 Conforming agent domains may include a duration in their response 558 indicating the number of seconds for which the salt and iteration 559 count will be valid. 561 The PKCS#5 PBKDF2 Authentication Scheme is not currently deployed 562 on the Second Life Grid. 564 4.2. Response 566 The response to the agent login message is notice of one of seven 567 "conditions": 569 o authentication success 571 o maintenance deferred success 573 o authentication non-success 575 o authentication failure 577 o agent selection failure 579 o "user intervention required" failure, and 580 o "non-specific" failure. 582 The specification recognizes three "non-failure" responses: 584 4.2.1. Success 586 Upon success, the agent domain will respond with a message containing 587 the "Agent Seed Capability". Receipt of this capability indicates 588 authentication was successful. This capability is then used for 589 further interactions with the system. 591 4.2.2. Maintenance Deferred Success 593 This condition indicates per-agent (or per-account) login-time 594 maintenance is being performed. It is not an error. The response 595 includes a maintenance cap the client application should use to get 596 information about currently executing maintenance. For more 597 information about maintenance, see the Maintenance section below. 599 4.2.3. Authentication Non-Success 601 Authentication Non-Success is the response given when a client 602 queries the agent domain for agent-specific or account-specific 603 authentication parameters. In that it is the expected response to 604 such a query, it is not an error or exception. But it is not an 605 indication of successful authentication. 607 4.3. Errors and Exceptions 609 4.3.1. Authentication Failure 611 An authentication failure indicates the client application did not 612 provide enough information to authenticate the account or the agent. 614 4.3.2. Agent Selection Failure 616 An agent selection failure occurs when an account authentication 617 request is ambiguous. In other words, the account a user has 618 attempted to use to log in is associated with more than one agent 619 account and the client application did not specify which account to 620 use. The response includes a list of first_name / last_name pairs. 621 It is expected that the client application will present this list to 622 the user and ask which agent to use. 624 4.3.3. "User Intervention Required" Failure 626 This error indicates that the agent domain cannot authenticate the 627 user for non-technical reasons. The protocol does not attempt to 628 describe why, or imply remediation for this error. But an agent 629 domain that returns this response MUST provide a URL containing a 630 message describing the condition leading to the error and 631 remediation, if known. 633 4.3.4. "Non Specific" Failure 635 This error indicates some other error exists which does not fall into 636 one of the previous six conditions. 638 4.4. Interface (POST) 640 The following text describes the LLIDL description of the agent_login 641 messages. 642 ; authenticators 644 ; hashed password authenticator 646 &authenticator = { 647 type: 'hash', ; identifies this as "hashed" type 648 algorithm: 'md5', ; 649 secret: binary ; hash of salt prepended to the password; 650 ; s = h( '$1$' | pw ) 651 } 653 ; challenge response style authenticator 655 &authenticator = { 656 type: 'challenge', ; identifies this as a "challenge response" 657 algorithm: 'sha256', ; 658 salt: binary, ; optional - default is ( 0x24, 0x31, 0x24 ) 659 secret: binary ; hash of the salt prepended to the password 660 ; s = h( salt | h( '$1$' | pw ) ) 661 } 663 ; PKCS#5 PBKDF2 style authenticator 665 &authenticator = { 666 type: 'pkcs5pbkdf2', ; identifies authenticator as PKCS#5 PBKDF2 667 algorithm: string, ; identifier for hash ('md5' or 'sha256') 668 salt: binary, ; optional - default is ( 0x24, 0x31, 0x24 ) 669 count: integer, ; optional - 1 used if not present 670 secret: binary ; hash of the salt prepended to the password 671 ; s = pbkdf2( h('$1$' | pw),salt,count,128) 672 } 674 ; identifier types 675 ; account identifier 677 &identifier = { 678 type: 'account', ; identifies this as an "account identifier" 679 account_name: string, 680 first_name: string, ; optional - first_name and last_name 681 last_name: string, ; identify agent to log in as for accounts 682 ; with more than one agent 683 } 685 ; agent identifier 687 &identifier = { 688 type: 'agent', ; identifies this as an "agent identifier" 689 first_name: string, 690 last_name: string, 691 } 693 ; request 695 &credential = { 696 identifier: &identifier, ; account or agent identifier 697 authenticator: &authenticator ; 'hash', 'challenge' 698 ; or 'pkcs5pbkdf2' 699 } 701 ; response 703 ; successful response 705 &response = { 706 condition: 'success', 707 agent_seed_capability: uri ; URL of the agent seed cap 708 } 710 ; authentication failure 712 &response = { 713 condition: 'key', 714 salt: binary, ; optional - salt for challenge and PKCS5 715 count: integer, ; optional - iteration count for PKCS5 716 duration: integer ; optional - the duration of the validity 717 ; period of salt and count values in 718 ; seconds 719 } 721 ; maintenance "non success" 722 &response = { 723 condition: 'maintenance', 724 maintenance_capability: uri, ; URL of the maintenance cap 725 completion: integer ; an estimate for maintenance duration 726 ; (in seconds) 727 } 729 ; agent select failure 731 &response = { 732 condition: 'select', 733 agents: [ string, string, ... ] 734 } 736 ; administrative failure 738 &response = { 739 condition: 'intervention', 740 message: uri ; a URI with human-readable text 741 ; explaining what the user must do to 742 ; continue 743 } 745 ; non-specific error 747 &response = { 748 condition: 'nonspecific', 749 message: string ; a string describing the failure 751 ; resource definition 753 %%agent_login 754 ->&credential 755 <-&response 757 5. Login-Time Maintenance (Resource Class) 759 5.1. Inputs 761 There are no parameters to a maintenance capability request. 763 5.2. Response 765 There are three responses to a maintenance capability: a description 766 of ongoing maintenance, a new maintenance capability describing 767 another sequence of maintenance transactions, or a seed capability. 768 These responses are identified with the condition items: 'ongoing', 769 'next' and 'complete'. 771 The 'ongoing' response to a maintenance capability request includes a 772 simple textual description of the maintenance performed, an estimate 773 for how long the maintenance is expected to take, and a validity 774 duration for the capability. The estimate for how long maintenance 775 will take is provided so client applications may provide feedback to 776 the user. The validity duration gives the viewer a minimum time 777 period the agent domain will maintain the maintenance capability. 779 When the agent domain returns a 'next' response, it indicates that 780 the current maintenance is complete, but a new maintenance must be 781 performed before the agent may be placed into a region. The 'next' 782 response includes the URL of the next maintenance capability as well 783 as an integer describing the minimum time period the agent domain 784 will maintain the maintenance capability. 786 When an agent domain returns a 'complete' response, it indicates that 787 all maintenance is complete. The response includes the agent seed 788 capability that may be used to place the user's avatar in a region. 789 It also includes an item describing the validity period for the 790 current maintenance capability. 792 5.3. Interface (GET) 794 The following text describes the LLIDL description of the agent_login 795 messages. 796 &response = { 797 condition: 'ongoing', 798 description: string, 799 duration: integer, ; seconds before maintenance is complete 800 } 802 &response = { 803 condition: 'next', 804 description: string, 805 maintenance_capability: uri ; URL for the next maintenance capability 806 } 808 &response = { 809 condition: 'complete', 810 agent_seed_capability: uri ; the agent's seed cap 811 } 813 %%maintenance 814 ->undef 815 <-&response 817 6. Security Considerations 819 RFC 3552 [RFC3552] describes several aspects to use when evaluating 820 the security of a specification or implementation. We believe most 821 common security concerns users of this specification will encounter 822 are more appropriately considered as transport, network or link layer 823 issues. However, the following "application security" issues should 824 be considered. 826 The MD5 cryptographic hash functions has been deprecated and SHOULD 827 be used only for compatibility with older applications. 829 The use of the hashed password authenticator could result in a replay 830 attack if not used in conjunction with an appropriate confidentiality 831 preserving transport. Implementations using the hashed password 832 authenticator SHOULD utilize appropriate encryption schemes such as 833 TLS [RFC5246] or S/MIME [RFC3851]. 835 7. IANA Considerations 837 This document has no actions for IANA. 839 8. References 841 8.1. Normative References 843 [I-D.hamrick-llsd] 844 Brashears, A., Hamrick, M., and M. Lentczner, "Linden Lab 845 Structured Data", 2008. 847 [I-D.ietf-oauth-authentication] 848 Hammer-Lahav, E., "The OAuth Protocol: Authentication", 849 draft-ietf-oauth-authentication-01 (work in progress), 850 July 2009. 852 [I-D.ietf-oauth-web-delegation] 853 Hammer-Lahav, E., "The OAuth Protocol: Web Delegation", 854 draft-ietf-oauth-web-delegation-01 (work in progress), 855 July 2009. 857 [I-D.lentczner-ogp-base] 858 Lentczner, M., "Open Grid Protocol: Foundation", 859 draft-lentczner-ogp-base-00 (work in progress), 860 March 2009. 862 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 863 April 1992. 865 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 866 Requirement Levels", BCP 14, RFC 2119, March 1997. 868 [pkcs5] Kaliski, B., "PKCS #5: Password-Based Cryptography 869 Specification Version 2.0". 871 [sha256] ""Federal Information Processing Standards Publication 872 180-2 (+ Change Notice to include SHA-224)". 874 8.2. Informative References 876 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 877 Text on Security Considerations", BCP 72, RFC 3552, 878 July 2003. 880 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 881 Extensions (S/MIME) Version 3.1 Message Specification", 882 RFC 3851, July 2004. 884 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 885 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 887 Appendix A. Acknowledgements 889 The author gratefully acknowledges the contributions of David Levine 890 and John Hurliman whose participation made this document apropos to a 891 wider range of use cases than would have originally been the case. 893 Authors' Addresses 895 Tess Chu 896 Linden Research, Inc. 897 945 Battery St. 898 San Francisco, CA 94111 899 US 901 Phone: +1 415 243 9000 902 Email: tess@lindenlab.com 903 Meadhbh Siobhan Hamrick 904 Linden Research, Inc. 905 945 Battery St. 906 San Francisco, CA 94111 907 US 909 Phone: +1 650 283 0344 910 Email: infinity@lindenlab.com 912 Mark Lentczner 913 Linden Research, Inc. 914 945 Battery St. 915 San Francisco, CA 94111 916 US 918 Phone: +1 415 243 9000 919 Email: zero@lindenlab.com