Search

RETS Change Proposal 41: ChangePassword Implementation
Author: Leendert Bijnagte
Organization: FNIS
Telephone: (612)661-1087
Address: 100 Washington Sq #900, Minneapolis, MN 55410
Email: lbijnagte@fnis.com
Status: Proposal
Date: 09/29/2003
Proposal Version: 1.7 and (earlier)
1. Synopsis
This proposal clarifies the implementation of the ChangePassword transaction.
2. Rationale
The implementation of the ChangePassword transaction in the compliance checker was significantly different from independently developed host versions although it mirrored that used in the reference implementation. Several implementation details (padding for the ECB version of DES and encoding) were overlooked and the specification of a 56 bit key when most DES routines require a 64 bit key (of which only 56 are actually used) led to confusion about the way to generate the 64 bits for those standardized DES encryption routines. Finally, the current specification is silent on exactly when the new password takes effect.
3. Proposal
3.1 Specification Changes

Section 9.1 titled Required Request Arguments needs to be modified to address the additional implementation details:

PWD ::= PWD=<Base64<DES( Password : UserName Padding )>>

This is the Base64 representation of the DES-encrypted UserName and Password. The new Password and the UserName are appended together with a colon and then padded with 1 to 8 bytes per section 9.7 and the resulting octets are encrypted using DES in Electronic Code Book  (ECB) mode. The DES key is constructed using the procedure in Section 9.6.

Section 9.6 titled Encryption Key Construction has item 3 modified to specify the 64 bit key:

3 The key is taken as the first 64 bits of the resulting hash value. Parity bits must be corrected for encoders that check parity.

Add a new section 9.7 ECB Padding

The input to the DES CBC encryption process shall be padded to a multiple of 8 octets, in the following manner. Let n be the length in octets of the input. Pad the input by appending 8-(n mod 8) octets to the end of the message, each having the value 8-(n mod 8), the number of octets being added. In hexadecimal, the possible paddings are: 01, 0202, 030303, 04040404, 0505050505, 060606060606, 07070707070707, and 0808080808080808. All input is padded with 1 to 8 octets to produce a multiple of 8 octets in length. The padding can be removed unambiguously after decryption.

Add a new section 9.8 Effect of Change

Servers that return a success status MUST accept the new password and reject the old password for all subsequent Login transactions and sessions. Servers that return a success status MAY require use of the new password for all subsequent transactions in the current session by issuing a WWW-Authenticate challenge for transactions that do not contain the correct credentials. 

Clients that do not receive a reply to this transaction SHOULD retain both the old and new password until the effect of the ChangePassword transaction can be ascertained via a successful Login  

3.2 Implementation Notes

Both clients and servers MAY implement this interpretation for all previous versions of the RETS specification.

4. Development Impact
No know cases of clients and servers successfully implementing a variant scheme exist, so incorporating these new implementation clarifications simplifies development of interoperable clients and servers.
5. Compatibility
Because this change involves clarifying the method for implementing a transaction which had no successful variant, no compatibility needs to be maintained other than with what has already been successfully implemented.
6. Proof/Need of Concept Examples
None.