Subject: RE: Comments Re: [seamoby] ct problem statement

From: "Louis-Nicolas Hamer" <[email-masked]>
Date: Mon, 4 Jun 2001 17:10:46 -0400

I think everyone is in agreement here but cannot see it.
 
What Gary is stating is CT MUST be secure. How to secure it is the 64 000$
question. IMHO,
we could and should re-use existing security mechanisms (e.g. IPSec, TLS).
If something
specific comes along that is specific to CT, we can address it at that
point.
 
But can we all agree that we don't need to re-invent a specific security
solution
for CT? Basically, you guys are stating that the IETF security area, with
all it's experts did not
do a good job designing current security solutions and that we need to
re-invent the wheel once
again.
 
Bottom line, the current requirement on security should be enough. It is not
possible, at this point,
to figure out the details of a security mechanisms. 
 
Cheers,
Louis-Nicolas

-----Original Message-----
From: Kenward, Gary [WDLN2:AN10:EXCH] 
Sent: Monday, June 04, 2001 12:28 PM
To: 'Michael Thomas'
Cc: [email-masked]'; 'seamoby'; 'Pat Calhoun'; [email-masked]
Subject: RE: Comments Re: [seamoby] ct problem statement

Well, to begin with, "at the operators option" would include 
the option to provide privacy or not to the service users. In 
a competitive environment, the user could then decide whether to 
subscribe to the service or not, if that privacy was not provided. 

As for securing "keys" (which is necessary to maintain the committed 
level of security that operator has chosen to support), as been discussed
repeatedly on this list, no one has suggesting transferring keys openly.
What I stated was that I do not understand where the requirements for CT
differ from any other secure data transfer between peers.

Gary 

> -----Original Message----- 
> From: Michael Thomas [ mailto:[email-masked] <mailto:[email-masked]> ] 
> Sent: Monday, June 04, 2001 11:33 AM 
> To: Kenward, Gary [WDLN2:AN10:EXCH] 
> Cc: [email-masked]'; 'seamoby'; 'Pat Calhoun'; [email-masked] 
> Subject: RE: Comments Re: [seamoby] ct problem statement 
> 
> 
> Gary Kenward writes: 
>  >   The second point troubles me somewhat: ct is essentially 
> an information 
>  > transfer operation. I do not understand (and I can only 
> state this as my 
>  > being confusion) why it is not enough to say that this 
> information transfer 
>  > must be secure. Why would a ct be any different from any 
> other data transfer 
>  > that needs to be secured? 
>  > 
>  >   I personally don't see any new vulnerabilities; based 
> upon my superficial 
>  > understanding of security, I read the examples you have 
> provided as specific 
>  > instances of general security problems which I understood 
> to have been 
>  > addressed. In other words, how are these scenarios not 
> already addressed by 
>  > the existing security solutions? 
>  > 
>  >   I am not against providing security for ct - not at all. 
> However, I do 
>  > want to ensure that security remains an option to the 
> operator (and is not 
>  > build into the protocol), the overhead imparted the ct can 
> be minimized, and 
>  > the performance goals attained. 
> 
>    Anything that transfers keys of any kind cannot be 
>    done "at the operator's option". There are also 
>    privacy issues which must be preserved for the MN 
>    as well. At a base level, any transfer of context 
>    must be at least as secure the mechanisms the 
>    MN and AR used to create the original context. 
>    Anything less is a breach to the MN. 
> 
>           Mike 
>

---

From: "Melinda Shore" <[email-masked]>
Date: Tue, 5 Jun 2001 08:06:29 -0400

> But can we all agree that we don't need to re-invent a specific 
> security solution for CT? Basically, you guys are stating that 
> the IETF security area, with all it's experts did not do a good 
> job designing current security solutions and that we need to
> re-invent the wheel once again.

I don't see anybody saying that.  There's actually a rich
set of security mechanisms published by the IETF - the task
is to identify the requirements and then choose the 
appropriate tool to solve the problem.  Context transfer
may have requirements, like performance, that would be
difficult to meet if you were to wave hands and use IKE to 
key up and establish SAs.  So while this isn't the time to
choose mechanisms it certainly is the time to be pretty
clear about what the requirements will be.  "Use existing
IETF protocols" will be one requirement, but there must be
others. 

Melinda