Subject: RE: Security stuff was RE: Comments Re: [seamoby] ct problem stat ement

From: Phillip Neumiller <[email-masked]>
Date: Tue, 5 Jun 2001 10:46:32 -0400

Yes, I am sorry for the sarcastic remark.  MIP is not reinventintg the
wheel,
the MAN in the middle attack was the reason IPsec could not be used (I
believe).
I hope that we can analyze the "applicability of IPsec" to SeaMoby CT
without
getting bogged down in reinventing IPsec here.  I hope that the SeaMoby
group
can answer the requirements issue in reverse here and ask what is wrong with
using IPsec for CT rather than what are all the possible attacks on the
planet
that could mess up CT....

Thanks,

Phil

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: Tuesday, June 05, 2001 10:42 AM
> To: 'seamoby'
> Cc: Phillip Neumiller
> Subject: Re: Security stuff was RE: Comments Re: [seamoby] ct problem
> statement
> 
> 
> Phillip Neumiller wrote:
> 
> >>> 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.
> > 
> > Why not?  That's what mobile IP has done... :-)
> 
> This needs additional information to be understood correctly.
> There were two problems.
> 
> 1. The Mobile IP group was instructed that use of AH was problematic
>    because the SPD selection mechanism did not mesh well with the
>    requirement to authenticate data in a destination option (vs., say,
>    authenticating the payload).
> 
> 2. Further, it was determined that providing the mechanism (Binding
>    Update) for enabling direct routes between mobile node and
>    correspondent node was inadequate unless there was also a
>    reasonable mechanism for creating the security association for
>    carrying out the needed authorization check.
> 
> The above quoted sentence _might_ be misinterpreted to mean that
> people in the mobile-ip working group did not want to use IPsec
> mechanisms.  That would be wrong.
> 
> Regards,
> Charlie P.
>

---

From: David Frascone <[email-masked]>
Date: Tue, 5 Jun 2001 09:51:55 -0500

I think I'm going off on a tangent, but at the IETF, wasn't it said that
the man-in-the-middle attack had no solution?  And, that the MITM attacks
were being ignored, since there was no solution at all, unless you had prior
knowledge (i.e. the public key) of the party you were communicating with?

-Dave

---

From: Mark Smith <[email-masked]>
Date: Tue, 05 Jun 2001 08:35:36 -0700

> knowledge (i.e. the public key) of the party you were communicating with?

...or, there is a trusted third party (Certificate Authority) whom you 
both trust to verify The Other Guy's(tm) identity sign The Other 
Guy's(tm) key.  Then, all you'd need to know is the CA's public key and 
you could verify that the key your getting belongs to who it caims to.

(NOTE:  I'm not aware of any of the CAs signing IPSec Identity Keys yet, 
so this may be of little use.  Of course, I've also not been looking for 
them, so they may exist; I've not checked.)

Of course, this puts trust in the CAs.  Who's heard about the 
disgruntled ex-Microsoft employee getting a cert in Microsoft's name?  :)

-Mark

---

From: Michael Thomas <[email-masked]>
Date: Tue, 5 Jun 2001 09:43:15 -0700 (PDT)

David Frascone writes:
 > the man-in-the-middle attack had no solution?  

   Sure it has a solution. Shared keys, kerberos, PKI's...

 > And, that the MITM attacks

   Without direct knowledge, or a trusted third party that
   is correct. That said, CT does *not* have the same
   situation. In fact, it's pretty much a poster child for
   where direct knowledge or third parties is completely
   appropriate.

		Mike