Luchesar V. ILIEV wrote:
> Come to think of this, why do we really need that "callback" test? I
> mean: we do expect only services to create policies, right? And only
> policies for "their" own resources, right?
>
> Which means that when a certain service requests to have a policy
> created for, e.g.
>
> http://serviceA.opentox.org/dataset/B
>
> then the policy SHOULD come from an IP address corresponding to the
> serviceA.opentox.org DNS name -- am I wrong in this assumption?
> Because, if the assumption is correct, then, bar any IP/DNS spoofing
> attempts, we could use only this simple check: whether the DNS name of
> the request corresponds to the URL that is requested to be protected.
>   
Simple and effective - I would vote for this solution.

Nina
> In other words, if the service gets a request for the resource above
> from an address, which reverse-resolves to, say, badguy.aol.com, then
> the policy service will reject the request straight away.
>
> Cheers,
> Luchesar
>
> P.S. Once SSL/TLS enters, it actually becomes even more hack-proof.
> Yes, DNS poisoning and IP spoofing are not unheard of, but if you
> actually require also _client_ certificate for any connections to the
> policy service (as opposed to OpenSSO, where this would make the
> things more complex for the users), then you could actually check the
> DNS name from that certificate. Again, it must correspond to the DNS
> name of the URL in the policy creation request. Seems simple and
> effective. Probably too simple, though, so I'm counting on you to
> catch if I'm missing something important.
>
>
> On Mon, Jun 28, 2010 at 22:08, Nina Jeliazkova <nina at acad.bg> wrote:
>   
>> Hi Andreas,
>>
>> Unless we invent specific query parameter/media type for the
>> "reachability test" , this could be quite inefficient.   For example, if
>> one happens to try to GET /dataset/{id} ,  for a large dataset , and
>> ignore the results , this will be a waste of resources (server, network
>> and perhaps client's ).
>>
>> Regards,
>> Nina
>>
>> chung wrote:
>>     
>>> Hi Andreas,
>>>   Is it possible to allow just web services to create policies prior to
>>> resource's actual creation? [I mean
>>> using some token of theirs identifying them as web services and not
>>> using other users' tokens]
>>> If one attempts a DOS attack you can just disable the attacker's account
>>> or if one creates policies in an
>>> unexpectedly large frequency you can block the account for some time. It
>>> would be more convenient if
>>> we removed such a restriction.
>>>
>>> Note: This is not an objection, it would be just easier to me to go
>>> without this restriction.
>>>
>>> Best regards,
>>> Pantelis
>>>
>>>
>>> On Mon, 2010-06-28 at 13:28 +0200, Andreas Maunz wrote:
>>>
>>>
>>>       
>>>> Dear all,
>>>>
>>>> I propose to make the A&A policy webservice more secure by checking
>>>> availability of resource URIs at policy upload time.
>>>> This is to tackle the issue of "pre-registration", i.e., to stop an
>>>> attacker from registering arbitrary "promising" resource URIs (not under
>>>> his control), by enforcing that every URI in a policy is actually reachable.
>>>> Being "reachable" means that the webservice at the corresponding URI
>>>> reacts by returning an arbitrary return code other than "404 (not found)".
>>>> If nothing speaks against that I will add the functionality within the
>>>> next few days. Please tell me, if you hold a different view on the issue.
>>>>
>>>> Best regards
>>>> Andreas
>>>> _______________________________________________
>>>> Development mailing list
>>>> Development at opentox.org
>>>> http://www.opentox.org/mailman/listinfo/development
>>>>
>>>>
>>>>         
>>> _______________________________________________
>>> Development mailing list
>>> Development at opentox.org
>>> http://www.opentox.org/mailman/listinfo/development
>>>
>>>       
>> _______________________________________________
>> Development mailing list
>> Development at opentox.org
>> http://www.opentox.org/mailman/listinfo/development
>>
>>     
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>   


-- 
---------------------------------
Dr. Nina Jeliazkova
Technical Manager
IdeaConsult Ltd.
1000 Sofia, Bulgaria
Tel: +359 886 802011
ICQ: 10705013
www: http://ambit.sourceforge.net
---------------------------------                          
PGP Public Key
http://cert.acad.bg/pgp-keys/keys/nina-nikolova-0xEEABA669.asc
	8E99 8BAD D804 1A43 27B7  7F87 CF04 C7D1 EEAB A669
---------------------------------------------------------------