idnits 2.17.1 draft-ietf-vwrap-authentication-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 5, 2010) is 5043 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) ** 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: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Virtual World Region Agent T. Chu 3 Protocol Linden Research, Inc. 4 Internet-Draft M. Hamrick 5 Intended status: Standards Track M. Lentczner 6 Expires: January 6, 2011 July 5, 2010 8 VWRAP Trust Model and User Authentication 9 draft-ietf-vwrap-authentication-00 11 Abstract 13 Authentication in the Virtual World Region Agent Protocol establishes 14 an application layer association between a client application and a 15 remote service responsible for managing the end user's identity. The 16 objective of authentication is to verify the user of a client 17 application possesses appropriate credentials before granting 18 capabilities sufficient to assert control over the user's agent and 19 digital assets. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 6, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 2. Agent Login (Resource Class) . . . . . . . . . . . . . . . . . 3 58 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1.1. The Account identifier . . . . . . . . . . . . . . . . 4 60 2.1.2. Flexible Authentication . . . . . . . . . . . . . . . 4 61 2.2. Service Location . . . . . . . . . . . . . . . . . . . . . 5 62 2.3. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.3.1. Account Identifier . . . . . . . . . . . . . . . . . . 5 64 2.3.2. Hashed Password Authenticator . . . . . . . . . . . . 5 65 2.3.3. Challenge-Response Authenticator . . . . . . . . . . . 5 66 2.3.4. PKCS#5 PBKDF2 Authenticator . . . . . . . . . . . . . 6 67 2.4. Response . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.4.1. Success . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.4.2. Maintenance Deferred Success . . . . . . . . . . . . . 7 70 2.4.3. Authentication Non-Success . . . . . . . . . . . . . . 7 71 2.5. Errors and Exceptions . . . . . . . . . . . . . . . . . . 7 72 2.5.1. Authentication Failure . . . . . . . . . . . . . . . . 7 73 2.5.2. User Intervention Required Failure . . . . . . . . . . 7 74 2.5.3. Non Specific Failure . . . . . . . . . . . . . . . . . 7 75 2.6. Preconditions . . . . . . . . . . . . . . . . . . . . . . 7 76 2.6.1. Client Preconditions . . . . . . . . . . . . . . . . . 7 77 2.6.2. Authentication Service Preconditions . . . . . . . . . 8 78 2.7. Postconditions . . . . . . . . . . . . . . . . . . . . . . 8 79 2.7.1. Client Postconditions . . . . . . . . . . . . . . . . 8 80 2.7.2. Authentication Service Postconditions . . . . . . . . 8 81 2.8. Side Effects . . . . . . . . . . . . . . . . . . . . . . . 8 82 2.9. Sequence of Events . . . . . . . . . . . . . . . . . . . . 9 83 2.10. Interface . . . . . . . . . . . . . . . . . . . . . . . . 10 84 3. Login-Time Maintenance (Resource Class) . . . . . . . . . . . 12 85 3.1. Service Location . . . . . . . . . . . . . . . . . . . . . 13 86 3.2. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 3.3. Response . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 3.4. Interface . . . . . . . . . . . . . . . . . . . . . . . . 13 89 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 90 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 91 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 6.1. Normative References . . . . . . . . . . . . . . . . . . . 15 93 6.2. Informative References . . . . . . . . . . . . . . . . . . 15 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 96 1. Introduction 98 Authentication is the first step in associating a client application 99 with virtual world services. The authentication service may have a 100 trust relationship with other services; before a client application 101 may interact with them, it must authenticate itself by presenting 102 credentials demonstrating its right to control the agent. 103 Authentication is the process of presenting a credential to the 104 authentication service and receiving a seed capability or an 105 actionable error description. 107 1.1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 2. Agent Login (Resource Class) 115 2.1. Introduction 117 Authentication begins by requesting the agent_login resource; that 118 is, sending a message to a well-known URL containing a message 119 constructed using rules defined using a supported serialization 120 scheme for use with the abstract type system 121 [I-D.ietf-vwrap-type-system]. The authentication service managing 122 this resource then makes an access control decision based on the 123 verity of the credential and the state of the service. 125 The authentication process results in one of seven classes of 126 response from the authentication service: 128 o success 130 o deferred success due to maintenance 132 o authentication non-success due to missing secret 134 o authentication failure 136 o "user intervention required" failure, and 138 o "non-specified" failure. 140 Responses to authentication requests are successes, non-successes and 141 failures. A "success" indicates the client application should have 142 enough information to progress past the authentication phase and 143 begin using the service. A "deferred success" implies use of the 144 system will continue after a "short" period. In either case, the 145 authentication service does not expect the client application to re- 146 submit the agent_login request. Authentication "non-success" results 147 from a client requesting authentication parameters. After sending a 148 "non-success", the authentication service expects the client to 149 resubmit the agent_login request "shortly." Failures of all type 150 indicate the authentication service believes a condition exists 151 requiring explicit user intervention. In the case of an 152 authentication failure, the user should either retry the 153 authentication request or recover their password. A failure due to 154 "user intervention required" indicates the authentication service 155 believes the user's account is in a state requiring "out of band" 156 recovery. Reading and accepting the authentication service's Terms 157 of Service or Critical Messages are examples of recovering from "user 158 intervention required" failures. Non-Specified failures indicate a 159 non-recoverable problem that is not defined in this specification. 161 The section below on Processing Expectations provides more guidance. 163 2.1.1. The Account identifier 165 Client applications encode user credentials using an "Account 166 Identifier." An "account" is an administrative object holding 167 information about the user: shared secret, a reference to an avatar 168 shape, a collection of owned virtual items, etc. 170 Please note this document does not imply a structure to the account 171 identifier. Though an authentication service may use an email 172 address as an account identifier, the protocol does not require it 173 and treats the identifier simply as an opaque sequence of octets. 175 2.1.2. Flexible Authentication 177 This revision of the Virtual World Region Agent Protocol defines, but 178 does not require the use of, three authentication schemes: hashed 179 password, challenge-response and PKCS#5 Key Derivation 2. 181 Implementers should also note that the authenticator is not required. 182 If an authenticator is not present in the agent_login request, the 183 authentication service SHOULD make a best-effort attempt to 184 authenticate the request from context. In some cases, the absence of 185 the authenticator will imply the authentication has already taken 186 place with OAuth or OpenID as described in the "Client Application 187 Launch Message" [I-D.ietf-vwrap-launch] document. In other 188 situations, the authentication service SHOULD examine the security 189 parameters of the transport. 191 2.2. Service Location 193 Each authentication service MUST have a service URL that is 194 communicated to the client application before authentication begins. 195 Some services will deploy a fixed, well-known URL while others may 196 choose to locate the agent_login resource behind a cryptographically 197 unguessable web capability.[I-D.ietf-vwrap-launch] 199 2.3. Inputs 201 2.3.1. Account Identifier 203 The account_name key in the credential provided to the authentication 204 service is used to identify the account. This is the opaque sequence 205 of octets used by the authentication service to identify the user. 207 2.3.2. Hashed Password Authenticator 209 When a hashed password is used as an authenticator, the string '$1$' 210 is prepended to the UTF-8 encoding of the password and processed with 211 the MD5 cryptographic hash function. [RFC1321] This revision of the 212 Virtual World Region Agent Protocol specification requires the use of 213 MD5 with the hashed password authenticator. It also requires the 214 presence of the algorithm key, and that the value of this key be the 215 string 'md5'. Note that future versions of this specification may 216 ALLOW or REQUIRE the use of other cryptographic hash functions. 218 2.3.3. Challenge-Response Authenticator 220 The Challenge-Response scheme allows the authentication service to 221 select a session specific "Salt" to be used in conjunction with the 222 user's password to generate an authenticator. In this scheme the 223 authenticator is the hash of the salt prepended to the hash of '$1$' 224 prepended to the password. This revision of the Virtual World Region 225 Agent Protocol specification requires the use of SHA256 with the 226 challenge-response authenticator. [sha256] It also requires the 227 presence of the algorithm key, and that the value of this key be the 228 string 'sha256'. Note that future versions of this specification may 229 ALLOW or REQUIRE the use of other cryptographic hash functions. 231 To retrieve a session specific salt for use with the Challenge- 232 Response authentication scheme from the authentication service, the 233 client application sends a login request with a Challenge-Response 234 authenticator without the secret item. If the agent domain supports 235 this authenticator, it MUST respond with a 'key' condition including 236 a salt and MAY include a duration in the response. If the duration 237 is present, it denotes the number of seconds for which the salt will 238 be valid. 240 2.3.4. PKCS#5 PBKDF2 Authenticator 242 The PKCS#5 PBKDF2 authenticator is an implementation of RSA Labs' 243 Public Key Cryptographic Standards #5 v2.1 Password Based Key 244 Derivation Function #2. [pkcs5] In this scheme, the string '$1$' is 245 prepended to the password is used in conjunction with a salt, 246 iteration count and hash function to generate an authenticator. This 247 revision of the Virtual World Region Agent Protocol specification 248 requires the use of SHA256 with the PKCS#5 PBKDS2 authenticator. It 249 also requires the presence of the algorithm key, and that the value 250 of this key be the string 'sha256'. Note that future versions of 251 this specification may ALLOW or REQUIRE the use of other 252 cryptographic hash functions. 254 As with the Challenge-Response authenticator, the authentication 255 service MUST include the salt and iteration count in its response to 256 an authentication request that is made without a secret item. 257 Conforming authentication services may include a duration in their 258 response indicating the number of seconds for which the salt and 259 iteration count will be valid. 261 2.4. Response 263 The response to the agent login message is notice of one of seven 264 "conditions": 266 o authentication success 268 o maintenance deferred success 270 o authentication non-success 272 o authentication failure 274 o "user intervention required" failure, and 276 o "non-specific" failure. 278 The specification recognizes three "non-failure" responses: 280 2.4.1. Success 282 Upon success, the authentication service will respond with a message 283 containing the "Agent Seed Capability". Receipt of this capability 284 indicates authentication was successful. This capability is then 285 used for further interactions with the system. 287 2.4.2. Maintenance Deferred Success 289 This condition indicates per-agent (or per-account) login-time 290 maintenance is being performed. It is not an error. The response 291 includes a maintenance cap the client application should use to get 292 information about currently executing maintenance. For more 293 information about maintenance, see the Maintenance section below. 295 2.4.3. Authentication Non-Success 297 Authentication Non-Success is the response given when a client 298 queries the agent domain for agent-specific or account-specific 299 authentication parameters. In that it is the expected response to 300 such a query, it is not an error or exception. But it is not an 301 indication of successful authentication. 303 2.5. Errors and Exceptions 305 2.5.1. Authentication Failure 307 An authentication failure indicates the client application did not 308 provide enough information to authenticate the account or the agent. 310 2.5.2. User Intervention Required Failure 312 This error indicates that the authentication service cannot 313 authenticate the user for non-technical reasons. The protocol does 314 not attempt to describe why, or imply recovery from this error. But 315 an authentication service that returns this response MUST provide a 316 URL containing a message describing the condition leading to the 317 error and remediation, if known. 319 2.5.3. Non Specific Failure 321 This error indicates some other error exists which does not fall into 322 one of the previous conditions. 324 2.6. Preconditions 326 2.6.1. Client Preconditions 328 It is generally assumed that before a user attempts to log into an 329 authentication service, they will not be actively connected to that 330 service. 332 It is also assumed that the user has registered their account; user 333 registration is outside the scope of this specification. 335 The client application SHOULD present the authentication service's 336 Terms of Service and Critical Messages and allow a user to accept or 337 decline them prior to attempting to authenticate. 339 2.6.2. Authentication Service Preconditions 341 If the authentication service requires users to read and agree to the 342 Terms of Service or acknowledge receipt of Critical Messages prior to 343 authentication, it must maintain a record of which accounts and 344 agents have accepted and acknowledged these items. 346 Authentication services that support the concept of "suspension" or 347 "disablement" should also maintain a record of which accounts and 348 agents are suspended or disabled. 350 2.7. Postconditions 352 2.7.1. Client Postconditions 354 Following successful authentication, the client application SHOULD 355 note that the agent has been authenticated to the authentication 356 service. The Virtual World Region Agent Protocol is NOT stateless. 358 2.7.2. Authentication Service Postconditions 360 After an account is authenticated, a seed capability is allocated for 361 the agent. The authentication service SHOULD maintain the 362 association between the account and the seed capability so it may be 363 re-used if the client attempts to re-authenticate the user before the 364 capability expires. 366 2.8. Side Effects 368 The authentication service SHOULD maintain the "presence" state of an 369 agent. This state should include the agent's seed capability. If a 370 previously authenticated and "present" agent re-authenticates 371 successfully, the authentication service MAY return the same seed 372 capability. 374 After successful authentication, it is expected the client will issue 375 a request on the seed capability. To defend against potential Denial 376 of Service attacks against the authentication service, the 377 authentication service MAY define a timeout period for the seed 378 capability. If the timeout period expires without a request being 379 made against the seed capability, that seed capability will expire. 380 Successful authentication of an agent who is "not present" has the 381 effect of starting this timer. 383 The Challenge-Response Authenticator is intended to be used with a 384 new, randomly generated salt for each authentication request. If the 385 authentication service supports the Challenge-Response authentication 386 scheme, it must maintain the "most recently generated salt" for some 387 period of time (generally until the expiration of the duration period 388 given in the authentication non-success response.) 390 After the salt has "timed out" following an unsuccessful Challenge- 391 Response authentication request, the authentication service MUST NOT 392 allow the use of a previous or fixed salt value. That is, it is not 393 correct, after the salt has expired, to use a null, fixed or previous 394 salt. The authentication service MUST generate a new salt and return 395 it to the client application. An unsuccessful authentication request 396 with the Challenge-Response scheme also has the side effect of 397 starting the salt duration timer. When this timer expires, the 398 authentication service MUST NOT allow authentication with previously 399 generated salts. 401 2.9. Sequence of Events 403 It is possible for an authentication request to occur in conditions 404 where multiple errors or exceptions COULD be returned. As the 405 protocol does not support reporting multiple failure conditions, the 406 following sequence is provided to determine the priority of failure 407 conditions. This sequence of events is motivated by the following 408 principles: 410 o The authentication service should leak no account status 411 information to an unauthenticated user. 413 o Maintenance should occur after successful authentication and 414 before account status checking in case maintenance involves the 415 representation of these states by the authentication service. 417 o The authentication service should check for "administrative 418 issues" after maintenance is complete. 420 The sequence for authentication is as follows. At the first error, 421 the system produces an appropriate error response. 423 1. If the authenticator provided is a Challenge-Response or PKCS#5 424 PBKDF2 type AND a secret is not included, the system returns an 425 authentication non-success response. 427 2. The secret and optional authentication parameters are used to 428 verify the client is in possession of the shared secret. If 429 authentication is unsuccessful, an authentication failure 430 response is returned. 432 3. If per-user login-time maintenance must be performed, the 433 authentication service allocates a maintenance capability and 434 returns it to the client application as a maintenance deferred 435 success response. 437 4. If an "administrative issue" exists such as the user is 438 suspended, banned, must agree to the terms of service or read 439 critical messages, the system returns a "user intervention 440 required" response, providing a URL referencing a web resource 441 explaining the administrative issue and describing remediation 442 steps. 444 5. Check to see if the authenticated agent is associated with an 445 agent seed capability already. If so, return a success response 446 referencing that seed capability. 448 6. Start the seed capability timer. Allocate an agent seed 449 capability and return it to the client application via a success 450 response. 452 2.10. Interface 454 The following text describes the interface description of the 455 agent_login messages.[I-D.ietf-vwrap-type-system] 457 ; authenticators 459 ; hashed password authenticator 461 &authenticator = { 462 type: 'hash', ; identifies this as "hashed" type 463 algorithm: 'md5', ; 464 secret: binary ; hash of salt prepended to the password; 465 ; s = h( '$1$' | pw ) 466 } 468 ; challenge response style authenticator 470 &authenticator = { 471 type: 'challenge', ; identifies this as a "challenge response" 472 algorithm: 'sha256', ; 473 salt: binary, ; optional - default is 0x24, 0x31, 0x24 474 secret: binary ; hash of the salt prepended to password 475 ; s = h( salt | h( '$1$' | pw ) ) 476 } 478 ; PKCS#5 PBKDF2 style authenticator 479 &authenticator = { 480 type: 'pkcs5pbkdf2', ; identifies authenticator as PKCS#5 PBKDF2 481 algorithm: string, ; identifier for hash ('md5' or 'sha256') 482 salt: binary, ; optional - default is 0x24, 0x31, 0x24 483 count: int, ; optional - 1 used if not present 484 secret: binary ; hash of the salt prepended to password 485 ; s = pbkdf2( h('$1$' |pw),salt,count,128) 486 } 488 ; request 490 &credential = { 491 account_name: string, 492 authenticator: &authenticator ; 'hash' 'challenge' or 'pkcs5pbkdf2' 493 } 495 ; response 497 ; successful response 499 &response = { 500 condition: 'success', 501 agent_seed_capability: uri ; URL of the agent seed cap 502 } 504 ; authentication failure 506 &response = { 507 condition: 'key', 508 salt: binary, ; optional - salt for challenge and PKCS5 509 count: int, ; optional - iteration count for PKCS5 510 duration: int ; optional - the duration of the validity 511 ; period of salt and count values in 512 ; seconds 513 } 515 ; maintenance "non success" 517 &response = { 518 condition: 'maintenance', 519 maintenance_capability: uri, ; URL of the maintenance cap 520 completion: int ; estimate for maintenance duration 521 ; (in seconds) 522 } 524 ; administrative failure 526 &response = { 527 condition: 'intervention', 528 message: uri ; a URI with human-readable text 529 ; explaining what the user must do to 530 ; continue 531 } 533 ; non-specific error 535 &response = { 536 condition: 'nonspecific', 537 message: string ; a string describing the failure 538 } 540 ; resource definition 542 %% agent_login 543 -> &credential 544 <- &response 546 3. Login-Time Maintenance (Resource Class) 548 An authentication service has the option of performing "per-user, 549 login-time maintenance" as part of the authentication sequence. 550 Performing maintenance after a user is authenticated and before an 551 avatar is "rezzed" in a region has several advantages: 553 o it reduces system-wide downtime 555 o it distributes maintenance across time, and 557 o it consumes computational resources only for those agents who use 558 the system 560 The authentication service signals it is performing maintenance by 561 returning a "Maintenance Capability" instead of a seed capability 562 following successful authentication. The maintenance capability 563 represents a finite sequence of transactions performed by the agent 564 domain on the user's behalf. It is expected that maintenance is a 565 task that will complete in a "tractable" amount of time. 567 The maintenance capability may be queried to retrieve information 568 about the transactions that are occurring, including: 570 o a textual description of the maintenance being performed 572 o an estimate for how long the maintenance will take to complete 574 3.1. Service Location 576 The authentication service may provide a maintenance capability to 577 the client application in response to successful authentication. 578 This capability is communicated as an URL to a web based service that 579 accepts network queries. 580 'maintenance' capability from 582 3.2. Inputs 584 There are no parameters to a maintenance capability request. 586 3.3. Response 588 There are three responses to a maintenance capability: a description 589 of ongoing maintenance, a new maintenance capability describing 590 another sequence of maintenance transactions, or a seed capability. 591 These responses are identified with the condition items: 'ongoing', 592 'next' and 'complete'. 594 The 'ongoing' response to a maintenance capability request includes a 595 simple textual description of the maintenance performed, an estimate 596 for how long the maintenance is expected to take, and a validity 597 duration for the capability. The estimate for how long maintenance 598 will take is provided so client applications may provide feedback to 599 the user. The validity duration gives the viewer a minimum time 600 period the authentication service will maintain the maintenance 601 capability. 603 When the authentication service returns a 'next' response, it 604 indicates that the current maintenance is complete, but a new 605 maintenance must be performed before the agent may be placed into a 606 region. The 'next' response includes the URL of the next maintenance 607 capability as well as an integer describing the minimum time period 608 the authentication service will maintain the maintenance capability. 610 When an authentication service returns a 'complete' response, it 611 indicates that all maintenance is complete. The response includes 612 the agent seed capability that may be used to place the user's avatar 613 in a region. It also includes an item describing the validity period 614 for the current maintenance capability. 616 3.4. Interface 618 The following text describes the interface description of the 619 agent_login messages. 621 &response = { 622 condition: 'ongoing', 623 description: string, 624 duration: int, ; seconds 'til maintenance is complete 625 validity: int ; seconds 'til this capability expires 626 } 628 &response = { 629 condition: 'next', 630 description: string, 631 maintenance_capability: uri, ; URL for the next maintenance cap. 632 validity: int ; seconds 'til this capability expires 633 } 635 &response = { 636 condition: 'complete', 637 agent_seed_capability: uri, ; the agent's seed cap 638 validity: int ; seconds 'til this capability expires 639 } 641 %% maintenance 642 <