Re: security review of enrp, asap, et al

[Ran Canetti]

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

[Ran Canetti]

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

[Lars Eggert-4]

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

_______________________________________________
rserpool mailing list
rserpool@...
https://www.ietf.org/mailman/listinfo/rserpool