IS: Response to ClientAuthentication Security Improvement Question WAS:Re: [Rets-dev] Username/Password and security policies

[Paul Stusiak]

At the risk of sounding pedantic and to try to answer the question of 
how Client Authentication improves security I offer the following:

[from below]
>  The scenario is a valid user trying to use an unauthorized client app.
>  Otherwise faking the user-agent doesn't matter. This is not a
>  "man-in-the-middle" attack.
>
>  If the user has a valid username/password, hasn't the MLS supplied the 
user
>  a client-auth password as well?
>
>  If so, I supply the expected user-agent header and client-auth 
password into
>  the RETS compliant but non-"MLS approved" client application, and now I'm
>  masquerading as the approved app.
>

Users should not receive the ClientAuthentication password. While RETS 
is silent about the exact mechanism that a US-Authorization password is 
delivered, the common scenario will be that an MLS contracts a server 
vendor to provide an MLS service. The MLS will enter into a contract 
with various client application vendors to access the data of the MLS 
service. The MLS will either have direct access or will instruct the 
server vendor to add the UserAgent and User Agent Password to the MLS 
service system. The client application vendor will incorporate the 
UserAgent value and the ClientAuthentication password into their 
application. Again, while RETS is silent on the exact mechanism, the 
common scenario is that the client application vendor creates an 
association between the MLS service, user names, UserAgent and MLS 
service ClientAuthentication password to ensure that they can get paid 
under the terms of the contractual agreement. In some cases, there will 
be a reporting mechanism to tell the MLS how many users are working with 
the client application in other cases, the mapping will be to allow the 
client application vendor to directly bill the individuals who are using 
the client application. ClientAuthentication passwords should be 
controlled by the vendor to vendor relationship and not by an Agent to 
vendor relationship.

The MLS or other body implementing the MLS service will want to ensure 
that the system meets the needs of the MLS. MLS service server vendors 
will want to ensure that the system can be economically delivered under 
the terms of the agreement between the vendor and the MLS. Both parties 
will need to know the impact of client applications on the system and 
will charge appropriately to ensure that their needs are met. In this 
case, only client application vendors that meet certain requirements 
will be permitted to connect to the system. The mere fact that an 
application is RETS compliant does not imply that it should be able to 
connect to a specific system. Business rules implemented by the MLS and 
server vendor will constrain application access to the system. The fact 
that an application is RETS compliant AND is authorized to connect 
should ensure that it can connect to a specific system. Your mileage may 
vary...

The case that an end user wants to use a non-MLS approved application by 
masquerading should not occur. Most, if not all, EULA (agreements) that 
I have seen forbid this case.

[from below]

>My question was how client auth helped data security and prevented users 
from using data in unauthorized ways.
>There are obviously scenarios that use client auth as it's solution.



UserAgent - the HTTP header, can be used by system vendors to identify 
applications and apply business rules that limits access to the system 
based on the user and the application that they are using. Since it is a 
plain-text header field, anyone with a very modest amount of technical 
skill could extract the UserAgent and use it for unauthorized purposes. 
It is also susceptible to replay attacks and possibly other types of 
attacks like man-in-the-middle.

Client Authentication provides system vendors with additional security 
to minimize the flaws of UserAgent alone - the possibility of replay or 
even more trivial misuses of access to the system. A vendor provides 
qualified individuals with the appropriate secret User Agent password 
that the individual incorporates into the client software. That 
individual should, through appropriate contract language, now have a 
duty to properly manage the secret password and to build an appropriate 
implementation of the algorithm described in the RETS1 documents. 
Because there is this password, which is hopefully encrypted in the 
application and only exposed in plain text in memory at the moment of 
use, and the use of the digest algorithm, the ability to fool the system 
is reduced. Server and client must exchange a handshake during the 
transaction that will allow the server to validate the application.

This does not prevent Client Authentication from being attacked. 
Sophisticated attackers could execute the client application within a 
tool like a debugger and directly examine the password when it is 
decrypted in memory if the application is outside of the client vendor's 
control, like on a desktop of an agent. Sophisticated attackers could 
decompile the client application if the application is outside of the 
client vendor's control like on a desktop of an agent. Sophisticated 
attackers cannot decompile or otherwise break the software that contains 
this password if the software never leaves the client facility - the 
majority of client applications that I have seen. So, the only way for a 
sophisticated attacker to recover the Client Authentication password is 
to use the well-understood attacks on MD5 algorithms that take a 
substantial amount of computing power or to extract the password from 
some internal human source. Thus, Client Authentication provides a 
mechanism for some delegation of responsibility from the server vendor 
to the client vendor. With logging, the breach can be traced back to a 
greater degree than with only the UserAgent. The responsible party can 
be better discovered.

Users are prevented from using the data in unauthorized ways by defining 
what the authorized uses are, providing controls to ensure that those 
uses can be managed - logging access and a method of monitoring who is 
accessing the system (ClientAuthentication, IP address, username, etc), 
monitoring and auditing the use of such data and finally, litigating to 
enforce the contractual agreement.

A system with a properly implemented Client Authentication raises the 
bar on security and the skill level to break such security. With no 
security - UserAgent in plain text, it is trivial to break any user 
application controls on data. With ClientAuthentication, the user 
application controls can still be broken, but the level of technical 
skill to break this becomes much higher. Breaking a properly implemented 
DigestAuthentication implementation is possible, however, the skill 
level required is very high. Breaking a poorly implemented DigestAuth 
algorithm is possible, but still requires a greater degree of skill.

In all cases, the security of data is not enforced by the use of either 
UserAgent or Client Authentication. It is enforced through appropriate 
contractual language, logging, monitoring and other techniques that 
these two RETS specification items support.

Paul
Falcon Technologies Corp.

Stuart Schuessler wrote:
>
> You did not offend. I just did not understand why you would dismiss a 
> part of the specification that others have a need for. You clearly did 
> not understand the need for client authentication so I did not 
> understand why you where commenting on it.
>
> It doesn’t matter.
>
> Stuart
>
> ------------------------------------------------------------------------
>
> *From:* Jeff Brush [mailto:jeffbrush at hotmail.com]
> *Sent:* Sunday, March 11, 2007 1:32 PM
> *To:* Stuart Schuessler
> *Cc:* rets-dev at rets.org
> *Subject:* RE: [Rets-dev] Username/Password and security policies
>
> Stuart.
>
> I'm sorry for offending.
>
> My question was how client auth helped data security and prevented 
> users from using data in unauthorized ways.
> There are obviously scenarios that use client auth as it's solution.
>
>
> Jeff
>
>
>
> ------------------------------------------------------------------------
>
> > From: sschuessler at tds.net
> > To: jeffbrush at hotmail.com
> > CC: rets-dev at rets.org
> > Subject: RE: [Rets-dev] Username/Password and security policies
> > Date: Sat, 10 Mar 2007 23:45:16 -0500
> >
> > >>I just don't believe client authentication adds much.
> >
> > Why would you say that? Such authority.
> >
> > There is a business need to limit access to select vendors by the MLS. In
> > same cases those vendor are required to pay a fee for access. If client
> > authentication is not used how would you solve that problem?
> >
> > Yes there is a special password that is shared between the MLS and Client
> > vendor.
> >
> > How do you get the password? Do you think the approved vendor is going to
> > give it to you? How are you going to masquerade?
> >
> > Are you implementing anything to do with client authentication? Have you
> > implemented anything with client authentication? Do you have a need for
> > client authentication? Are you just commenting for the heck of it?
> >
> > I believe I was originally answering someone else's question that had a
> > business need for client authentication. It was a valid answer based 
> on the
> > specification. Whether you think it adds much is not really relevant.
> >
> > Stuart
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Jeff Brush [mailto:jeffbrush at hotmail.com]
> > Sent: Friday, March 09, 2007 7:02 PM
> > To: 'Stuart Schuessler'
> > Cc: rets-dev at rets.org
> > Subject: RE: [Rets-dev] Username/Password and security policies
> >
> > The scenario is a valid user trying to use an unauthorized client app.
> > Otherwise faking the user-agent doesn't matter. This is not a
> > "man-in-the-middle" attack.
> >
> > If the user has a valid username/password, hasn't the MLS supplied 
> the user
> > a client-auth password as well?
> >
> > If so, I supply the expected user-agent header and client-auth 
> password into
> > the RETS compliant but non-"MLS approved" client application, and now I'm
> > masquerading as the approved app.
> >
> >
> > If, on the other hand, the client application and server vendors exchange
> > the password without the user's involvement, then the MLS can be 
> marginally
> > more secure in the knowledge that the client app is the application it
> > claims it is. Is this how it is done?
> >
> > I am not saying RETS is not secure. I just don't believe client
> > authentication adds much.
> >
> > Jeff
> >
> > -----Original Message-----
> > From: Stuart Schuessler [mailto:sschuessler at tds.net]
> > Sent: Friday, March 09, 2007 6:23 PM
> > To: 'Jeff Brush'; 'Colby Ackerfield';
> > Subject: RE: [Rets-dev] Username/Password and security policies
> >
> > >>How are client authentication passwords really any less easy to fake?
> >
> > How can you fake the client authentication?
> >
> > a1 ::= MD5( product : UserAgent-Password ) ua-digest-response::= HEX( 
> MD5(
> > HEX(a1): RETS-Request-ID : session-id :
> > version-info))
> >
> > I suppose if the RETS-Request-ID and session-id were empty then it would
> > always be the same hash, but if it is implemented correctly it would be
> > difficult to fake. How would you do it?
> >
> > Stuart
> >
> > -----Original Message-----
> > From: Jeff Brush [mailto:jeffbrush at hotmail.com]
> > Sent: Friday, March 09, 2007 4:07 PM
> > To: 'Stuart Schuessler'; 'Colby Ackerfield'; rets-dev at rets.org
> > Subject: RE: [Rets-dev] Username/Password and security policies
> >
> >
> > Stuart Schuessler wrote:
> >
> > > You probably would want to implement the client authentication as well.
> > > Just checking the user-agent is easy to fake. A person can do it with
> > firefox. If
> > > you do not implement the client authentication then anyone with a login
> > to the MLS
> > > system and access privileges can download your entire database and sell
> > it to a
> > > moving company or any number of data aggregators.
> >
> > How are client authentication passwords really any less easy to fake?
> > And how does client authentication prevent the user from selling the 
> data?
> >
> > At best, client authentication (the RETS-UA-Authorization header in RETS
> > 1.7) provides a method for MLSs to limit which client applications may
> > access their systems.
> >
> > Jeff Brush
> > Ronin Technologies
> >
> >
>
> ------------------------------------------------------------------------
>
> Discover the new Windows Vista Learn more! 
> <http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Rets-dev mailing list
> Rets-dev at rets.org
> http://lists.rets.org/mailman/listinfo/rets-dev
>