Subject: RE: [mobile-ip] comments on draft-mkhalil-mobileip-ipv6-sap-00.tx t

From: Phil Roberts <[email-masked]>
Date: Mon, 2 Apr 2001 12:50:11 -0400

Before you go too far down the road debating what should and shouldn't (or
will and won't) be done by this working group, it might be better to wait on
the statement we're working on about how to proceed with securing MIP v6
binding updates which should be out by the end of the day.

-----Original Message-----
From: Phil Neumiller [mailto:[email-masked]]
Sent: Monday, April 02, 2001 12:33 PM
To: Haseeb Akhtar; [email-masked]
Subject: Re: [mobile-ip] comments on draft-mkhalil-mobileip-ipv6-sap-00.tx t

Hello Haseeb, 
 
Some comments below.
 
----- Original Message ----- 
From: Haseeb  <mailto:[email-masked]> Akhtar 
To: [email-masked]' <mailto:[email-masked]'>

Cc: 'Phil Neumiller' <mailto:[email-masked]>  
Subject: RE: [mobile-ip] comments on draft-mkhalil-mobileip-ipv6-sap-00.tx t

Comments below. 

-----Original Message----- 
From: Phil Neumiller [ mailto:[email-masked]
<mailto:[email-masked]> ] 
To: mobile-ip 
1).  This draft belongs in the security working area of the IETF. 

2).  The MIP group is not qualified to make a security assesment of this
draft. 

=> I will let the co-chairs/AD decide that. As far as we know, the WG is
looking 

In the IETF, the chairs are to guage the WG consensus on issues not make

decisions like this.

=> for a security solution for IPv6. The IESG also has specifically
requested 
=> for such in the mailing list. A lot of discussions for last few days, 
=> too, has been around this very topic. 

This is good.  Which list are your referring to BTW?

3).  Why should the security association between an MN and a CN be all 
       that much different from other types of clients and servers and peers

       that run on the Internet?  Why enmesh the security terminology with 
       MIP terminology?  (cohesion is still a bad design choice after all
these 
        years).  Build a generalized solution for the Internet that MIP can
use. 

=> Since this is MIP WG and we are particularly concerned about a problem 
=> that involves CN and MN and this interface happens to use Binding Update
/ 
=> Binding Request etc. 

That is fine.  What I suggest is that use your draft as a requirements
document

and feed it to the security working group and let them work on solutions.
The

MIP WG is not qualified to perform crypt-analysis and build
crypto-graphically

strong systems nor is it chartred to do so.  This is a waist of everybodies
time

on this list.

4).  In the Abstract,  How fast is "fast"?  What is the baseline? 

=> Phil, if you feel comfortable, we can take out the reference to "fast"
from 
=> the draft in the next revision. Our objective was to propose a baseline
solution 
=> to the security problems of IPv6. 

On less you have some kind of baseline its a marketing term.

5).  Can't a security association be used for all sorts of other good stuff
besides 
       MIP binding updates (related to 2 above). 

=> Of course, it can. The main question, however, does the proposed scheme
satisfy 
=> dissatisfy the requirements of this WG. 

What are the requirements of this WG?  Where are those documented?

6).  As for the rest of the draft, I saw no references to the specific
Diffie Hellman 
       work you were applying, no references to patents you were using
(expired 
       or not), I saw one vague reference to some of Charlie's work, I am 
       supposed to believe that this work will lead to something
cryptographically 
       secure? 

=> That is an oversight. We will include all the references in the next
version. 
=> I'm not aware of any patent that needed to be used. Any help in this
regard 
=> will be appreciated. 

Diffie Hellman public key exchange was patented and the rites were

owned by RSA part of pkix and some of these patents expired a few years
back.

I am very surprised by your question and again, I believe this work belongs
in

a security WG.

       I believe this type of work needs to be reviewed in the MIP WG after
it 
       goes through some severe scrutiny in the security area where there 
       are domain experts in security.  

=> Agreed. 

Good then, could the name of the draft be changed to "req" for requirements.

This is the way the AAA work in the MIP WG is proceeding.

       Most people in the MIP WG want 
       mobile security in the worse way, but are not security domain
experts. 

Best Regards, 

Phil

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 2 Apr 2001 22:04:19 +0200

>  > >        MIP terminology?  (cohesion is still a bad design choice after all these
>  > >         years).  Build a generalized solution for the Internet that MIP can use.
>  > 
>  > Unfortunately, we've just been made very aware that Binding Updates _cannot_
>  > use any generalized IPsec solution.  This is a very long subject, but the
>  > very short version is that existing implementations cannot do the right
>  > thing according to the way they look up entries in their SPDs.
> 
>    I don't think that's what has been said at all.
>    There are three overall problems with IPsec in the
>    mipv6 draft that I know about:
> 
>    1) Use of AH for a destination option is a little
>       dodgy. I believe that was Bill Sommerfeld's
>       comment. However, using ESP/NULL for a BU
>       which wasn't destination option (ie, just
>       make it a separate ICMP, say) wouldn't be
>       problematic on that front.
> 
>    2) For the general anonymous browsing kind of 
>       problem which is the general case for MN->CN
>       communication, the implications of global
>       PKI's inherent for key exchange
>       are... daunting to say the least, and quite
>       possibly undesirable even if possible. A
>       more decentralized approach would be better
>       if possible
> 
>    3) There are performance implications for large
>       servers, both in round trips and CPU
>       complexity using IKE (or even KINK) that
>       we'd like to have a way to opt-out if 
>       possible. To some degree this is a cop
>       out and only postpones when we won't be
>       placing packets over insecure links, but
>       it's also today's reality. I'm sort of 
>       ambivalent on this point.
> 
>    That said, I still think it would be very
>    useful to still salvage the ability to use
>    IPsec for BU's (mostly by fixing (1)). For the
>    other considerations, we're going to need
>    something different.
> 
	=> That's my understanding too. I think the SPD
	issue is definitely solvable. The major issue is 
	the key exchange and the use of PKI.

	Hesham