Virtual World Region Agent                                        T. Chu
Protocol                                           Linden Research, Inc.
Internet-Draft                                                M. Hamrick
Intended status: Standards Track                            M. Lentczner
Expires: January 6, 2011                                    July 5, 2010


               VWRAP Trust Model and User Authentication
                   draft-ietf-vwrap-authentication-00

Abstract

   Authentication in the Virtual World Region Agent Protocol establishes
   an application layer association between a client application and a
   remote service responsible for managing the end user's identity.  The
   objective of authentication is to verify the user of a client
   application possesses appropriate credentials before granting
   capabilities sufficient to assert control over the user's agent and
   digital assets.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 6, 2011.

Copyright Notice

   Copyright (c) 2010 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Chu, et al.              Expires January 6, 2011                [Page 1]


Internet-Draft            VWRAP Authentication                 July 2010


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Agent Login (Resource Class) . . . . . . . . . . . . . . . . .  3
     2.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
       2.1.1.  The Account identifier . . . . . . . . . . . . . . . .  4
       2.1.2.  Flexible Authentication  . . . . . . . . . . . . . . .  4
     2.2.  Service Location . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Inputs . . . . . . . . . . . . . . . . . . . . . . . . . .  5
       2.3.1.  Account Identifier . . . . . . . . . . . . . . . . . .  5
       2.3.2.  Hashed Password Authenticator  . . . . . . . . . . . .  5
       2.3.3.  Challenge-Response Authenticator . . . . . . . . . . .  5
       2.3.4.  PKCS#5 PBKDF2 Authenticator  . . . . . . . . . . . . .  6
     2.4.  Response . . . . . . . . . . . . . . . . . . . . . . . . .  6
       2.4.1.  Success  . . . . . . . . . . . . . . . . . . . . . . .  6
       2.4.2.  Maintenance Deferred Success . . . . . . . . . . . . .  7
       2.4.3.  Authentication Non-Success . . . . . . . . . . . . . .  7
     2.5.  Errors and Exceptions  . . . . . . . . . . . . . . . . . .  7
       2.5.1.  Authentication Failure . . . . . . . . . . . . . . . .  7
       2.5.2.  User Intervention Required Failure . . . . . . . . . .  7
       2.5.3.  Non Specific Failure . . . . . . . . . . . . . . . . .  7
     2.6.  Preconditions  . . . . . . . . . . . . . . . . . . . . . .  7
       2.6.1.  Client Preconditions . . . . . . . . . . . . . . . . .  7
       2.6.2.  Authentication Service Preconditions . . . . . . . . .  8
     2.7.  Postconditions . . . . . . . . . . . . . . . . . . . . . .  8
       2.7.1.  Client Postconditions  . . . . . . . . . . . . . . . .  8
       2.7.2.  Authentication Service Postconditions  . . . . . . . .  8
     2.8.  Side Effects . . . . . . . . . . . . . . . . . . . . . . .  8
     2.9.  Sequence of Events . . . . . . . . . . . . . . . . . . . .  9
     2.10. Interface  . . . . . . . . . . . . . . . . . . . . . . . . 10
   3.  Login-Time Maintenance (Resource Class)  . . . . . . . . . . . 12
     3.1.  Service Location . . . . . . . . . . . . . . . . . . . . . 13
     3.2.  Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     3.3.  Response . . . . . . . . . . . . . . . . . . . . . . . . . 13
     3.4.  Interface  . . . . . . . . . . . . . . . . . . . . . . . . 13
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15




Chu, et al.              Expires January 6, 2011                [Page 2]


Internet-Draft            VWRAP Authentication                 July 2010


1.  Introduction

   Authentication is the first step in associating a client application
   with virtual world services.  The authentication service may have a
   trust relationship with other services; before a client application
   may interact with them, it must authenticate itself by presenting
   credentials demonstrating its right to control the agent.
   Authentication is the process of presenting a credential to the
   authentication service and receiving a seed capability or an
   actionable error description.

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.  Agent Login (Resource Class)

2.1.  Introduction

   Authentication begins by requesting the agent_login resource; that
   is, sending a message to a well-known URL containing a message
   constructed using rules defined using a supported serialization
   scheme for use with the abstract type system
   [I-D.ietf-vwrap-type-system].  The authentication service managing
   this resource then makes an access control decision based on the
   verity of the credential and the state of the service.

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

   o  success

   o  deferred success due to maintenance

   o  authentication non-success due to missing secret

   o  authentication 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



Chu, et al.              Expires January 6, 2011                [Page 3]


Internet-Draft            VWRAP Authentication                 July 2010


   begin using the service.  A "deferred success" implies use of the
   system will continue after a "short" period.  In either case, the
   authentication service does not expect the client application to re-
   submit the agent_login request.  Authentication "non-success" results
   from a client requesting authentication parameters.  After sending a
   "non-success", the authentication service expects the client to
   resubmit the agent_login request "shortly."  Failures of all type
   indicate the authentication service 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 authentication service
   believes the user's account is in a state requiring "out of band"
   recovery.  Reading and accepting the authentication service'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.

   The section below on Processing Expectations provides more guidance.

2.1.1.  The Account identifier

   Client applications encode user credentials using an "Account
   Identifier."  An "account" is an administrative object holding
   information about the user: shared secret, a reference to an avatar
   shape, a collection of owned virtual items, etc.

   Please note this document does not imply a structure to the account
   identifier.  Though an authentication service 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.

2.1.2.  Flexible Authentication

   This revision of the Virtual World Region Agent Protocol defines, but
   does not require the use of, three authentication schemes: hashed
   password, challenge-response and PKCS#5 Key Derivation 2.

   Implementers should also note that the authenticator is not required.
   If an authenticator is not present in the agent_login request, the
   authentication service SHOULD make a best-effort attempt to
   authenticate the request from context.  In some cases, the absence of
   the authenticator will imply the authentication has already taken
   place with OAuth or OpenID as described in the "Client Application
   Launch Message" [I-D.ietf-vwrap-launch] document.  In other
   situations, the authentication service SHOULD examine the security
   parameters of the transport.




Chu, et al.              Expires January 6, 2011                [Page 4]


Internet-Draft            VWRAP Authentication                 July 2010


2.2.  Service Location

   Each authentication service MUST have a service URL that is
   communicated to the client application before authentication begins.
   Some services will deploy a fixed, well-known URL while others may
   choose to locate the agent_login resource behind a cryptographically
   unguessable web capability.[I-D.ietf-vwrap-launch]

2.3.  Inputs

2.3.1.  Account Identifier

   The account_name key in the credential provided to the authentication
   service is used to identify the account.  This is the opaque sequence
   of octets used by the authentication service to identify the user.

2.3.2.  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
   Virtual World Region Agent 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.

2.3.3.  Challenge-Response Authenticator

   The Challenge-Response scheme allows the authentication service 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 Virtual World Region
   Agent 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 authentication service, the
   client application sends a login request with a Challenge-Response
   authenticator without the secret item.  If the agent domain supports
   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.



Chu, et al.              Expires January 6, 2011                [Page 5]


Internet-Draft            VWRAP Authentication                 July 2010


2.3.4.  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 string '$1$' is
   prepended to the password is used in conjunction with a salt,
   iteration count and hash function to generate an authenticator.  This
   revision of the Virtual World Region Agent 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 authentication
   service MUST include the salt and iteration count in its response to
   an authentication request that is made without a secret item.
   Conforming authentication services may include a duration in their
   response indicating the number of seconds for which the salt and
   iteration count will be valid.

2.4.  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  "user intervention required" failure, and

   o  "non-specific" failure.

   The specification recognizes three "non-failure" responses:

2.4.1.  Success

   Upon success, the authentication service 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.





Chu, et al.              Expires January 6, 2011                [Page 6]


Internet-Draft            VWRAP Authentication                 July 2010


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

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

2.5.  Errors and Exceptions

2.5.1.  Authentication Failure

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

2.5.2.  User Intervention Required Failure

   This error indicates that the authentication service cannot
   authenticate the user for non-technical reasons.  The protocol does
   not attempt to describe why, or imply recovery from this error.  But
   an authentication service that returns this response MUST provide a
   URL containing a message describing the condition leading to the
   error and remediation, if known.

2.5.3.  Non Specific Failure

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

2.6.  Preconditions

2.6.1.  Client Preconditions

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

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




Chu, et al.              Expires January 6, 2011                [Page 7]


Internet-Draft            VWRAP Authentication                 July 2010


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

2.6.2.  Authentication Service Preconditions

   If the authentication service 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.

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

2.7.  Postconditions

2.7.1.  Client Postconditions

   Following successful authentication, the client application SHOULD
   note that the agent has been authenticated to the authentication
   service.  The Virtual World Region Agent Protocol is NOT stateless.

2.7.2.  Authentication Service Postconditions

   After an account is authenticated, a seed capability is allocated for
   the agent.  The authentication service SHOULD maintain the
   association between the account and the seed capability so it may be
   re-used if the client attempts to re-authenticate the user before the
   capability expires.

2.8.  Side Effects

   The authentication service 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 authentication service MAY return the same seed
   capability.

   After successful authentication, it is expected the client will issue
   a request on the seed capability.  To defend against potential Denial
   of Service attacks against the authentication service, the
   authentication service 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.




Chu, et al.              Expires January 6, 2011                [Page 8]


Internet-Draft            VWRAP Authentication                 July 2010


   The Challenge-Response Authenticator is intended to be used with a
   new, randomly generated salt for each authentication request.  If the
   authentication service 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 authentication service 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 authentication service 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
   authentication service MUST NOT allow authentication with previously
   generated salts.

2.9.  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
   principles:

   o  The authentication service 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 authentication service.

   o  The authentication service 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.



Chu, et al.              Expires January 6, 2011                [Page 9]


Internet-Draft            VWRAP Authentication                 July 2010


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

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

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

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

2.10.  Interface

   The following text describes the interface description of the
   agent_login messages.[I-D.ietf-vwrap-type-system]

   ; 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 password
                             ;   s = h( salt | h( '$1$' | pw ) )
   }

   ; PKCS#5 PBKDF2 style authenticator




Chu, et al.              Expires January 6, 2011               [Page 10]


Internet-Draft            VWRAP Authentication                 July 2010


   &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: int,             ; optional - 1 used if not present
     secret: binary          ; hash of the salt prepended to password
                             ; s = pbkdf2( h('$1$' |pw),salt,count,128)
   }

   ; request

   &credential = {
     account_name: string,
     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: int,              ; optional - iteration count for PKCS5
     duration: int            ; optional - the duration of the validity
                              ; period of salt and count values in
                              ; seconds
   }

   ; maintenance "non success"

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

   ; administrative failure

   &response = {



Chu, et al.              Expires January 6, 2011               [Page 11]


Internet-Draft            VWRAP Authentication                 July 2010


     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


3.  Login-Time Maintenance (Resource Class)

   An authentication service has the option of performing "per-user,
   login-time maintenance" as part of the authentication sequence.
   Performing maintenance after a user is authenticated and before an
   avatar is "rezzed" in a region has several advantages:

   o  it reduces system-wide downtime

   o  it distributes maintenance across time, and

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

   The authentication 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 agent
   domain on the user'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




Chu, et al.              Expires January 6, 2011               [Page 12]


Internet-Draft            VWRAP Authentication                 July 2010


3.1.  Service Location

   The authentication service may provide a maintenance capability to
   the client application in response to successful authentication.
   This capability is communicated as an URL to a web based service that
   accepts network queries.
   'maintenance' capability from

3.2.  Inputs

   There are no parameters to a maintenance capability request.

3.3.  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',
   '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 authentication service will maintain the maintenance
   capability.

   When the authentication service 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 authentication service will maintain the maintenance capability.

   When an authentication service 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.

3.4.  Interface

   The following text describes the interface description of the
   agent_login messages.





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


Internet-Draft            VWRAP Authentication                 July 2010


   &response = {
     condition: 'ongoing',
     description: string,
     duration: int,               ; seconds 'til maintenance is complete
     validity: int                ; seconds 'til this capability expires
   }

   &response = {
     condition: 'next',
     description: string,
     maintenance_capability: uri, ; URL for the next maintenance cap.
     validity: int                ; seconds 'til this capability expires
   }

   &response = {
     condition: 'complete',
     agent_seed_capability: uri,  ; the agent's seed cap
     validity: int                ; seconds 'til this capability expires
   }

   %% maintenance
   <<response


4.  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].


5.  IANA Considerations

   This document has no actions for IANA.





Chu, et al.              Expires January 6, 2011               [Page 14]


Internet-Draft            VWRAP Authentication                 July 2010


6.  References

6.1.  Normative References

   [I-D.ietf-vwrap-type-system]
              Brashears, A., Hamrick, M., and M. Lentczner, "VWRAP :
              Abstract Type System for the Transmission of Dynamic
              Structured Data", July 2010.

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              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]   United States National Institute of Standards and
              Technology, "Federal Information Processing Standards
              Publication 180-2 (+ Change Notice to include SHA-224)",
              August 2002.

6.2.  Informative References

   [I-D.ietf-vwrap-launch]
              Hamrick, M. and J. Hurliman, "VWRAP : Client Application
              Launch Message", draft-ietf-vwrap-launch-00 (work in
              progress), July 2010.

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











Chu, et al.              Expires January 6, 2011               [Page 15]


Internet-Draft            VWRAP Authentication                 July 2010


Authors' Addresses

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

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


   Meadhbh Siobhan Hamrick
   P.O. Box 783
   Boulder Creek, CA  95006
   US

   Phone: +1 650 283 0344
   Email: OhMeadhbh@gmail.com


   Mark Lentczner

   Email: mark@glyphic.com



























Chu, et al.              Expires January 6, 2011               [Page 16]