Search

RETS Change Proposal 9: Client Software Validation
Author: Bruce Toback
Organization: OPT, Inc.
Telephone: (602)996-8601
Address: 11801 N. Tatum Blvd. Ste. 142, Phoenix AZ 85028
Email: btoback@optc.com
Status: Proposal
Date: 06/16/2002
Proposal Version: 1.0
1. Synopsis
This proposal replaces the current authorization scheme with one built on RFC 2617.
2. Rationale
The current authorization specification in RETS contains several ambiguities that have caused problems between client and server vendors. In addition, RETS servers currently do not have a method of validating authorized client software on a given system. The only current check of a User Agent's identity is the USER-AGENT in the http header, but client software can spoof the User-Agent header and use a valid UserID and Password to gain access. There is thus no secure way of allowing an MLS to enforce business rules regarding authorized user-agents.

RFC 2617 can solve both these problems: it is a widely-implemented industry standard and has a facility for client authentication. This change proposal specifies the replacement of the existing authorization and authentication with RFC 2617, and specifies the method of computing the cnonce element in the Authorization header to allow for client authentication.

3. Proposal
3.1 Specification Changes

Sections 4.3 - 4.5 of the specification are removed and the text is changed to refer to RFC 2617.

The server MAY require the client to authenticate itself using the cnonce parameter on the Authorization header.

The cnonce is calculated as:

cnonce ::= <H(unquoted nonce-value ":" client-password-value)>"

3.2 Implementation Notes

Servers SHOULD implement this new feature as a transition by supporting clients both with and without client passwords.

4. Development Impact
Because the changes described in this proposal are optional, there is no forced development impact.
5. Compatibility
Because this change involves a change in the method gaining access, RETS clients that do not support the client password will not be able to access a RETS server that requires it.
6. Proof/Need of Concept Examples
None.