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

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 7 Jul 2010 11:29:46 -0700

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/ * [email-masked]

---

From: "Robert G. Jakabosky" <[email-masked]>
Date: Wed, 7 Jul 2010 17:59:22 -0700

On Wednesday 07, Meadhbh Hamrick wrote:

<snip>
>   specification may ALLOW or REQUIRE the use of other cryptographic

<snip>

>   TLS [RFC5246] or S/MIME [RFC3851].

What use is the "Hashed Password Authenticator", if the transport needs to be 
encrypted?  That SHOULD needs to be a REQUIRED.  If an attacker picks up the 
hashed password even once they will be able to login to the account any time 
they want, even if the service later only allows the use of 
the "Challenge-Response Authenticator".  Since the same hashed password can 
be combined with the challenge salt.

I think the "Hashed Password Authenticator" needs to be replaced with 
a "Password Authenticator" that REQUIRES the use of an encrypted transport 
and sends the password instead of a hashed password.  Websites that have 
login forms use HTTPS to protect the user's password.  The browser doesn't 
send a hashed password to the server.  The use of password hashing on 
websites is to protect the password stored in a database encase some someone 
hacks the site and gets a copy of the password table.  That hashing is done 
on the server-side not the client-side.

A "Password Authenticator" would also allow companies like LindenLab to 
continue to work with the md5 hashed passwords stored in their database.  It 
would also allow companies in the future to migrate (i.e. rehash) the 
passwords stored in their database when it comes time to replace a broken 
hash algorithm.

-- 
Robert G. Jakabosky

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 7 Jul 2010 19:52:14 -0700

okay... a little background on hashed authenticators...

the original hashed authenticator was going to be used to replicate SL's
functionality of sending the non-salted, non-iterated, hash of a long-term
password.

but we wanted to have something better, so someone came up with the
challenge response scheme for use with the summer 2008 interop trial
(thought honestly, i don't think it was deployed.)

then i came up with the idea of using the PKCS#5 password based key
derivation function (PBKDF.)

and then the world went on until john hurliman and i were both trying to
figure out how to leverage OpenID and OAuth in VWRAP. that's where the CALM
message stuff came from. originally we were going to have the CALM message
include a "one time use" shared secret that the web-auth system would tell
the client and tell the VWRAP auth service about. then john came up with the
idea of putting the agent_login resource behind a web capability, so he
could just use proof of possession of the capability as authorization to log
in.

so now we're writing standards docs and we're talking about layering VWRAP
application layer object access across at least three different transports:
HTTP(S), XMPP and RTP. granted, it's probably unlikely that people are going
to attempt to send login credentials over RTP, but i used to work with game
programmers, so i've seen some pretty crazy things.

so the reason we say SHOULD instead of MUST is that we don't know if the
deployer will secure their network with IPSec, a Link Encryptor or TLS.
HTTPS requires the use of HTTP as a transport, and we're not entirely
certain that everyone wants to do that.

so in the proud tradition of internet standards everywhere, we will allow
implementers to shoot themselves in the foot if they really feel they need
to.

On Wed, Jul 7, 2010 at 5:59 PM, Robert G. Jakabosky
<[email-masked]>wrote:

> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>