Search

RETS Change Proposal 36: Client Software Validation
Author: Stuart Schuessler & Leendert Bijnagte
Organization: MarketLinx & FNIS
Telephone: (865)218-3606 & (612)661-1087
Address: P.O. Box 24119, Knoxville, TN 37933-2119 & 100 Washington Sq #900, Minneapolis, MN 55410
Email: sschuessler@marketlinx.com & lbijnagte@fnis.com
Status: Proposal
Date: 06/08/2002
Proposal Version: 1.5
1. Synopsis
This proposal replaces the current method of validating client software to be sure it is authorized to access a RETS Server.
2. Rationale
The current method of validating client software to the server imposes a large burden on the RETS client to handle all aspects of Digest Authentication instead of relying on popularly available tools.  It also requires servers that wish to authenticate client software to employ Digest Authentication for the user and to integrate this functionality with any tools their system might supply for doing so. This proposal decouples the client software authentication from user authentication. It uses existing headers in conjunction with a single new header as previously proposed and the same out-of-band UserAgent-Password of the previous scheme.
3. Proposal
3.1. Specification Changes

Section 3.5 titled Optional Client Request Header Fields needs to be modified to add support for the new header:

RETS-UA-Authorization ::= RETS-UA-Authorization: ua-method ua-digest-response
ua-method ::= "Digest"
ua-digest-response ::= <">*LHEX<">

The ua-digest-response value is computed as:

ua-digest-response ::= <MD5( product ":" UserAgent-Password ":" RETS-Request-ID ":" session-id ":" version-info )>

where the product is the first product value taken from the User-Agent header, the UserAgent-Password is a secret shared between the server software and the client software, the RETS-Request-ID is the value taken from the RETS-Request-ID header (missing or empty at the discretion of the client), the session-id is the value taken from the RETS-Session-ID in the Cookie header (missing or empty at the discretion of the server), and version-info is the value taken from the RETS-Version  header. Leading and trailing spaces are removed from all values.

The UserAgent-Password secret is shared between the client software and server software by a method outside the scope of this specification.

A server MAY require a valid RETS-UA-Authorization header on any transaction. The 20037 error response code specified for Login MAY be sent in response to any transaction.

3.2 Implementation Notes

Both clients and servers MAY implement this new feature without discarding the previous cnonce based authorization scheme. Servers MAY choose to require the new scheme. Clients SHOULD implement the new scheme.

4. Development Impact
Clients and servers using the cnonce scheme MAY continue to use it for a mutually agreed transition period. New implementations SHOULD use the  new scheme.
5. Compatibility
Because this change involves a change in the method for gaining access, RETS clients that do not support the method required by a RETS server will not function with that server.
6. Proof/Need of Concept Examples
None.