Re: Security and Cookies -- IETF #59 issue

Maureen,

one comment:
the cookie os reflected by the PU and provided by the PE to the APAP 
layer as a bytes
string. So it is up to the application to sign/encrypt the cookie in 
the case that
the PU<->PE communication is not secured. For the PU it does not 
matter. For the PE
the point is that the state required for signature verification and/or 
decryption
has to be shared between the PEs. But since all this is application 
level stuff this
should not be considered in RSerPool. The application level state 
sharing is out of
scope.

Best regards
Michael

On 18. Mar 2004, at 1:59 Uhr, Qiaobing Xie wrote:

> Maureen,
>
> I am fully with you on this issue and agree with your assessment.
>
> regards,
> -Qiaobing
>
> [email protected] wrote:
>
>> A question was raised at IETF #59 about the security of information 
>> in the cookies passed between the PE and PU.  My response was that 
>> this is not mentioned in the threat document.  We are required to 
>> secure the Rserpool infrastructure but not the application. In any 
>> case, I said I thought that this probably should be brought up the 
>> threat document.
>> Cookies are passed via the Rserpool control channel.  In the case of 
>> TCP as the transport, the group reached consensus that the data and 
>> control channel must always be multiplexed.  Therefore, the cases: a) 
>> control channel is secured; data channel is not
>> b) data channel is secured; control channel is not
>> are not allowed.  It is even hard to understand what this really 
>> means from a security point of view.
>>   The agreement to require multiplexing results in the following 
>> cases:
>> 1) the multiplexed control channel -data channel is secure OR
>> 2) the multiplexed control channel - data channel is not secured
>> In my opinion, you get what you pay for and what makes sense.  If you 
>> are going to secure both the data and control, then the cookies are 
>> secured.  If you are not going to secure the data and control; then 
>> the cookies are not secured either.  Seems from this example that we 
>> made a good decision.
>> Any comments on this issue?  After we debate it I can add the 
>> consensus to the threat document if appropriate.
>> -- maureen
>> _______________________________________________
>> rserpool mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/rserpool
>
>
> _______________________________________________
> rserpool mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rserpool
>