RE: [Sipping] comments on draft-tschofenig-sipping-captcha-00.txt

["Jeremy Barkan \(DigitalShtick\)" <[e-mail]>]

Hi Jonathan - 

At a first glance - CAPTCHA can be susceptible to all the attacks one can
get in a challenge type protocol - such as man-in-the-middle, replay and so
on. HASHCASH uses a hash that includes SIP header fields from the current
SIP Session - and we should think about how to make sure that the CAPTCHA is
also linked to the session and would not be reused.

Is this addressed in the app interaction framework you refer to ?

There are some other general CAPTCHA security issues that are important to
consider as well [ there has to be a wide enough set of CAPTCHA to make
dictionary attacks unfeasible and so on ] 

Regards


Jeremy

-----Original Message-----
From: Jonathan Rosenberg [mailto:[e-mail]] 
Sent: Friday, July 13, 2007 6:10 PM
To: IETF Sipping List
Subject: [Sipping] comments on draft-tschofenig-sipping-captcha-00.txt

Interesting draft, a few comments.

Firstly, I disagree strongly that the app interaction framework cannot 
be reused for this. The draft makes several statements about its 
applicability, all of which are wrong:

> Since there are different
>    solutions for different cases, the UAC needs to indicate the
>    supported application user interaction mechamisms when issuing a SIP
>    request.  This might be too a heavy requirement for solving the user
>    interaction needs related to SPIT challenges. 

Firstly, it wasn't clear to me how the proposed mechanism solves this 
either. WHen the server rejects the request and provides the captcha 
challenge, how does it know which challenge to issue? It depends on the 
capabilities of the user and UA. So, same problem.

Secondly this hardly seems like a hard problem to solve. The INVITE 
contains an Accept contact header field with the object types it can use.

The draft also says:

> Also, the application
>    interaction framework requires that a dialog exists before initiating
>    or accepting any user interaction requests.  In case of SPIT
>    challenges the user interaction must happen during the dialog
>    establishment so it seems that the application interaction framework
>    cannot be directly used as a solution.

This is false. THe dialog can be early. The application would send a 
provisional response and then issue the REFER to an HTTP URL, which can 
be used to retrieve exactly the same object you have specified, if you like.

Using the dialog event package also allows better performance since you 
don't have to retry the INVITE, the call just proceeds.


My second comment is, I'm not convinced a separate object format is 
needed for the challenge. Certainly in email systems today and web 
systems there is not; its just an HTTP interaction. I suspect you are 
worried about more limited user interfaces that don't have a general 
purpose web browser? You might want to motivate this a bit.

-JOnathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[e-mail]                              FAX:   [phone]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP



_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP