Subject: RE: Consumer Authorization of PH

From: David Burdett <[email-masked]>
Date: Wed, 23 Sep 1998 08:33:29 +0100

We didn't authenticate the Payment Handler in OTP since all OTP really
does is carry a payment protocol. This means that it's up to the Payment
Protocol to do its own authentication to check that a payment is being
done to the correct organisation and stop the transaction if its not.

You could argue that if you're using a simple payment method like SCCD
where you just give the Payment Handler your credit card number, then
you will possibly have the risks which you suggest. However today
zillions of people are doing just this some without using SSL and some
with and nobody seems to be complaining.

Spoofing the payment handler becomes a problem then people will have an
incentive to use a more secure payment method like SET.

Any more thoughts anybody. This is one we should discuss.

David

>----------
>From: 	Andrew Drapp[SMTP:[email-masked]]
>Sent: 	22 September 1998 05:09
>To: 	[email-masked]'
>Subject: 	Consumer Authorization of PH
>
>
>There may be a need for the Consumer to authenticate the Payment Handler 
>before sending the PaymentRequest message.  Imagine a situation where 
>someone sets up a PH and then spoofs the IP of a known PH.  When the 
>consumer sends the PaymentRequest message, it could be intercepted by the 
>fake PH.
>
>In the current version of the specs, a trading exchange cannot be 
>temporarily suspended and an authentication exchange started.  Since 
>everything is signed and is assumed to be going over a secure channel (ssl), 
>it seems that there is no reason that a PH or DH would need to authenticate 
>a consumer.  Furthermore, it was mentioned at Reston that the fake PH would 
>have to decrypt the offer exchange messages in order to successfully spoof a 
>PH. I don't think this is quite true.  Once a hacker knows what PH a 
>merchant uses, and what brands, he can set up a fake PH at his leisure.
>
>The simplest way to solve this would be to leave it up to the implementation 
>of the client OTP software.  Something like having a checkbox somewhere 
>saying "Send Authorization Request and wait for verification before sending 
>Payment Request."  There should  be little problem adding an 
>AuthReq/AuthResp between the OfferResp and the PayReq messages.
>
>Does this seem like something we should solve in OTP, or leave as an 
>exercise for the reader?  Does anyone have any suggestions on how to change 
>OTP to allow for the consumer to Authenticate the Payment Handler before any 
>personal information is sent?
>
>Regards,
>
>Andrew Drapp
>
>--
>Andrew Drapp
>[email-masked]
>Hitachi Systems Development Laboratory
>1099 Ozenji, Asao, Kawasaki, 215-0014 JAPAN
>TEL:+81-44-966-9111   FAX:+81-44-966-1796
>Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F
>
>
>-----------------------------------------------------------------------
>Message addressed to: [email-masked]
>Archive available at: http://www.elistx.com/archives/ietf-trade/
>To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
>body to: [email-masked]
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mondex International Limited
47-53 Cannon Street, London  EC4M 5SQ
England
Registered No: 3122085, England

Telephone No: +44 (0)171 557 5000
Web Site: http://www.mondex.com
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]