Re: [Rserpool] security review of enrp, asap, et al

On Mon, 16 Jun 2008, 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...

I meant threats 1 and 2 in the security considerations sections of the
asap and enrp documents. sorry for the inclarity.

>
> 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
rserpool@ietf.org
https://www.ietf.org/mailman/listinfo/rserpool