[vwrap] adding transport and capability auth types, removing MD5

[Meadhbh Hamrick <[e-mail]>]

so i made some quick mods to the auth draft to remove MD5 and add the
transport and capability authenticator types. sections 2.3, 2.10 and 4 have
changed, here's the new sections. changes are highlighted. does this look
about right to everyone else?

the new section 2.3

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 SHA256 cryptographic hash function [sha256].  This revision of
  the Virtual World Region Agent Protocol specification requires the
  use of SHA256 with the hashed password 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.*

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.

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.3.5.  Capability Authenticator

  The VWRAP Client Application Launch Message document
  [I-D.ietf-vwrap-launch] describes a technique for using "web based"
  authentication services such as OAuth [RFC5849] or OpenID [OPENID].
  One technique for ensuring the security of the client application
  launch message is for it to reference an agent_login resource on a
  web capability.  Because the address of the capability is
  cryptographically unguessable, it is assumed that only the
  authenticated client will know the resource's address.

  In this use case, the client does not need to include proof of a
  shared secret in the agent_login request itself.  Knowledge of the
  agent_login's address carries equivalent proof of the client's
  authorization.

  The "capability authenticator" is used in this use case.
  Authentication services are to interpret it's presence in an
  agent_login request as signaling the use of a previously established
  web based authentication service.  Authentication services that do
  not offer web based authentication MUST return an authentication
  failure response.

2.3.6.  Transport Based Authenticator

  Authentication messages may flow over transports that provide
  authentication or authorization.  HTTP Basic Authentication, Digest
  Authentication [RFC2617] and TLS Client Certificates [RFC5246]are
  popular techniques for authenticating one end of a network connection
  at the transport level.Though the objective of VWRAP authetication is
  to verify the origin integrity of an "application layer" entity, such
  credentials sometimes span layers.  In some environments, application
  layer credentials are assumed to be available to the transport.

  Guidelines for transport-based authentication are provided later in
  this document.  Conformant implementations wishing to use transport
  layer authentication MUST signal their intent by including a
  "transport" type authenticator in the agent_login message.

  Note there are no map elements save the "type" indicator in the
  transport based authenticator.  This is because actual authentication
  data is provided by the transport.*

the new section 2.10

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: '*sha256*',    ;
    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

  &authenticator = {
    type: 'pkcs5pbkdf2',    ; identifies authenticator as PKCS#5 PBKDF2
    algorithm: string,      ; identifier for hash ('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)
  }

*   ; Capability

  &authenticator = {
    type: 'capability'      ; identifies "capability" authentication
  }

  ; Transport

  &authenticator = {
    type: 'transport',      ; identifies "transport based" auth
  }*

  ; 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 = {
    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

the new section 4

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.

  *A previous version of this document specified the use of the MD5
  cryptographic hash function [RFC1321].  Its use has been deprecated
  and MUST NOT be used with VWRAP agent_login requests.*

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

-cheers
-meadhbh

--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [e-mail]