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

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