Re: security review of enrp, asap, et al

Hi, Ran,

since Magnus is on vacation, let me follow up by asking whether you  
think the remaining issue is a critical one for an Experimental  
protocol suite, or whether you think that describing it as something  
the experimenters need to be aware of would be sufficient?

Thanks,
Lars

On 2008-6-16, at 21:26, ext Ran Canetti wrote:

>
>
> I have been asked to review the revised versions of these documents  
> (from May 29). Of the concerns I raised in the original review blow,  
> the second one was addressed, by requiring authenticated  
> communication. The first concern (potential abuse of the system by a  
> legitimate-but-savvy user or server) does not seem to have been  
> addressed. Note that this concern does not seem to be solvable using  
> standard authentication mechanisms (Such as TLS etc), since the  
> problem is not an authentication problem. One solution is proposed  
> in my note below. I'm sure other solutions exist as well.
>
> Also, regarding security threats 1 and 2: I'm not sure how mutual  
> authentication helps against a malicious ENRP server or a malicious  
> PE.
> They can be completely authentic, yet malicious/hacked...
>
> Hope this helps,
> Ran
>
>
>
> On Sun, 4 May 2008, Ran Canetti wrote:
>
>>
>>
>> *I have reviewed these documents as part of the security  
>> directorate's
>> *ongoing effort to review all IETF documents being processed by the
>> *IESG.  These comments were written primarily for the benefit of the
>> *security area directors.  Document editors and WG chairs should  
>> treat
>> *these comments just like any other last call comments.
>>
>>
>> I have been asked to review:
>>
>>           draft-ietf-rserpool-asap-19
>>           draft-ietf-rserpool-common-param-16
>>           draft-ietf-rserpool-enrp-19
>>           draft-ietf-rserpool-policies-08
>>
>> Overall, the documents seem to be well presented and well organized.
>> The main comment I have is that I didnt see enough attention paid  
>> to potential attacks by legitimate pool users and/or pool members.
>>
>> One issue is that legitimate users may choose to not follow the  
>> proposed policies regarding choice ofservers (namely, members in  
>> the pool).
>> If the "choose a member at random" policy is employed, then a pool  
>> user can always set its "random coices" so that it picks a  
>> partiuclar pool member. This bypasses the "load asharing" idea  
>> behind the policy.
>> another issue is that a pool member (or server) may report a wrong  
>> policy to a user.
>>
>> The threats draft, draft-ietf-rserpool-threats I-D, does not seem  
>> to address such issues. However, I think these issues fit nicely  
>> within the scope of this protocol suite (if not here, then where  
>> else). In addition, there do exist simple ways to mitigate some  
>> attacks of this sort:
>>
>> To mitigate the first attack, the protocol may require the pool  
>> user to "prove" to the pool member that the pool member was chosen  
>> "randomly", say by demonstrating that the random choice was the  
>> result of applying some hash function to a public nonce. Different  
>> methods may be appropriate for other member scheduling policies.
>>
>> To mitigate the second attack, the protocol might require the pool  
>> server (or members) to sign the policy sent to the user, in a way  
>> that will allow the user to later hold the server accountable to  
>> the policy.
>>
>> Best,
>> Ran
>>
>>
> _______________________________________________
> rserpool mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rserpool